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There exist many unknowns in the practical application of time-sharing 
system concepts which are not readily approachable until sufficient ex- 
perience is gained and a time-sharing vehicle is available for study pur- 
poses. Research into time-sharing system problems may be initiated when 
the above criteria are reasonably satisfied and the pressure of the pro- 
duction effort is relieved. However, it is not too early to delineate 
appropriate considerations for on-going research and development. This 
note contains an initial set of researchable areas which will be modified 
as time and experience progress; 


5 . Object Program Systems - 

|je subsfcW**D|jW ftn" l oocument contains no classified infc 


A methodology whereby object programs may be 
associated into a single object system with 
intercommunication between modular entities. 
One might consider here, the type of programs 
/rhich lend themselves best to time-sharing. 


focument contains no classified information it has not been cleared for open publication by the Department of Defense. 


- The nature, benefits, and requirements of coding a 
program statement or a line at a time. Also, the 
building of programs with library routines. 


4. Group Interaction - Enabling several users to interact with each other 

via communication with a common (object) program 
(system). This implies multiple input control of 
program response and selective multiple output. 
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« 3 . Testing ■» 
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Bh 

Q M E 


Techniques for rapid, on-line perusal and manipulation 
or modification of object program code and/or data. 
This includes the problem of using source language vs. 
machine language. 


Encompasses all phases of on-line program debugging 
and the need for appropriate on-line test tools. 

a. Grammar checking 

b. Parameter testing 

c. String testing 

d. System (object) testing 

e. Associating test data with programs 
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2§mlc Relocatabllity - The dynamic assignment of main and auxiliary 

storage to programs and data. This area will 
also consider scheduling needs for the hier- 
archical treatment of available storage. 

Scheduling and Priority - Optimizing the effectiveness of the Time- 
sharing system in servicing various kinds and 
numbers of user programs and needs, e.g., 
large programs, small programs, production 
programs, high data-rate programs, etc.' 
Priority considerations involve time dependent 
and input dependent response needs. 

guage Compatibility - The coexistence of different language types 

within the Time-Sharing system, i.e., POL’s, 
MOL’s and list processors. In addition, the 
optimal language system for time-sharing 
activities is also researchable. 

at (interrupt) and Output Processing - Involves the problem of over- 
head efficiency related to 
rapid response to user needs. 

jjment Support - Covers a broad spectrum of areas where hardware can 
facilitate time-sharing system operations. 

a. Memory protection 

b. Expanding memory storage 

c. Interrupts (time, error, inputs, outputs, etc.) 

d. Display devices 

e. Input keyboard devices 

f. Light pens 

g. Graphical input and output devices 

h. Bulk input and output devices (Remote) 


Multiple-Computer Operations 


The application of time-sharing concepts 
to multiple-computer and satellite com- 
puter configurations. 


12 * Automated Documentation - Permitting the Time-Sharing system and resident 

programs to be self-explanatory to any potential 
user. 

13. Agp li cat ions - Various areas of time-sharing applicability, e.g., data 

retrieval, learning machines, desk calculator, command 
planning, language construction, etc. 

14 ’ .Qp-Linc Technical Manag ement of Time-Sharing System - The problem of 

proper user utilization of a time-sharing system, par- 
ticularly for production programming, and user activity 
accounting and control. ' 



21 February 1963 


(Last Page) 


N-19846/OOO/0O 


Other researchable areas will appear on the 6cene as they are conceived or 
tripped over in the ensuing months of involvement with time-sharing concepts 
and implementation. There will be an assortment of problem areas which can 
be investigated as the opportunity arises. 
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TESTING THE ARPA-SDC TIME-SHARING SYSTEM 


The design of the initial phase of the ARPA-SDC Time-Sharing System will 
attempt to accomodate a variety of user needs in a reasonable manner. Ii 
asmuch as the variables involved are numerous and the precise effects of 
various situations cannot be determined completely beforehand, it is des; 
ble that a realistic shakedown of the system be accomplished during the < 
of system development and checkout. The method proposed in this note vi: 
involve a set of checkout programs which can be adjusted by system test 
personnel to simulate the various forms of stress which user programs wi] 
exercise upon the Time-Sharing System. 

The test program system will be designed to grow as the Time-Sharing syBl 
capability expands. Thus, initial stress conditions will teat the 


Operational Variables 


me atirii— oix. nme-bharing system will be expected to 
large n 'amber of users in a "simultaneous” fashion, 
these users will be operating at very remote locations 
activities will vary and be reflected, in an r ~ ' 

The Time-Sharing system will be required to handle 
the gamut of user programs, 1 " 
gram types and numbers of "simultaneous 


1 service a relatively 
In addition, many of . 
The nature of user 
assortment of object programs. 

in a reasonable fashion 

both from the point of view of individual pro- 
simultaneous" object programs. 

The most significant general variables which must be considered in a time- 
sharing system are: 

(1) Number of users 

(2) Complexity of user operations (object programs) ' 

(3) Capacity and capabilities of computer configuration 

The third item is a relatively fixed condition, although the Q-32 configurat 
will be expected to expand. The first two considerations are of maior im- 
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An expansion may be performed, on the user's role and the type of object 
programs in the system* This can provide a guide for testable system 
environment conditions and situations. It may also proye useful as Input to 
the recording and accounting functions of the Time-Sharing system. 

User Factors * 

1. No. of users (grouped by complexity of object programs) 

2. Input rate (TTY) 

3. Response time' from computer 

U. Error rates for Executive commands (indicator of convenience of system 
communications) 

5 . Communication volume (non-program) between remote stations 

o. Communication response (non-program) time between remote stations 


The above lists are not intended to be comprehensive, but are indicative of 
the kind of information which reveal the magnitude of demands made upon the 
Time-Sharing system. 


In addition to a concern over the users' operations, the operation of the 
Time-Sharing system will be significant in terms of: 

1. Overhead time 

2. Core and drum. space needs of the Time-Sharing system itself. 


During the initial developmental phase of the ARPA-SDC Time-Sharing system, 
the areas of interest will include only simple user operations and the 
effectiveness of the systejn in servicing these users. It is not necessary 
to develop a complex simulation system, such as was used in SAGE, to repro- 
duce complete user activity. This would be a large task in itself. Instead, 
simple "do-nothing" routines, which run under the direct control of 
system test personnel, would exercise various bounds of system capacity. 


Size of program (operating form, including core data storage) 

Operating time 

On-line or production mode 

Utilization of i/o (frequency, volume, and type) 

(a) High-speed channels 
•(b) Low- speed channels 

Amount of auxiliary storage required by object program for its own use. 
Time-dependency of operation (e.g., periodic, immediate response to 
randomly occurring request, priority) 

Intercommunication with other object programs 

Source language (for debugging, updating, etc.) . ' - 


Testing the System 


1 . 

2 . 

3 . 

h. 
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The results of such testing could then be used for extrapolation of system 
capacity by analytic methods, as well as for improvement of the developmental 

system. ' . v 

The test programs will be able to change their effects on the system in two 
ways. First, the test user can specify the version of the program to be 
loaded using the LOAD command. If another version is desired subsequently, 
a new LOAD will introduce it into the system. The second method will permit 
the test program to change dynamically while it is operating in the system. 

The desired parameters will be accepted through teletype inputs and the pro- 
gram will alter itself accordingly. The choice of which method can be used 
is dependent on the particular testing parameters involved and the existent 
Time -Sharing system capabilities. 

The following variables for test programs are currently being considered: 

1. Operating time 

2. Input rate (TTY) 

3. Output rate (TTY) 

4. Utilization of I/O 

5. Program size 

6. On-line, production mode 

Other variables such as priority, intercommunication with other object’pro- 
grams, etc., will be investigated at a later date. 

Initial Test Program 

The initial test module will accept teletype inputs containing instructions 
in the form of parameter values. These parameters will communicate to the 
program the length of the "do-nothing" loop. Upon completing the operation of 
this loop, the program will report back to the test user for further instructions. 

At each teletype station, test personnel will be able to manipulate these 
testr "object" programs for various combinations of operating times. The 
Time-Sharing system's effectiveness for handling these conditions can then 
be observed. 

Subsequent test modules will add the capability for changing the amounts of 
teletype output to each user, the number and frequency of use of various l/o 
channels, and the amount of core and drum space required. This evolution 
will take place in step with the developmental needs of the ARPA-SDC Time- 
sharing system. 
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Introduction 


The first phase of the ARPA-SDC Time-Sharing System (TSS Model l) is expected 
to he available for use in the summer of 1963. At that time, the Q-32 will 
be utilized in the time-sharing mode for a large portion of its operations. 
Consequently, potential users of the Q-32 within SDC should be acquainted 
with time-sharing procedures and prepared with compatible object programs to 
run with TSS Model 1. This document is intended to provide a general overview, 
of time-sharing operations and a guide to programming for the time-sharing 
l' environment. This document will be updated as the system development evolves 
and as hardware implementation affords expanded system capability. 

Concepts of Time-Sharing 

The purpose of time-sharing is to make the computer more economical and accessi- 
ble to increase human productivity. "Time-sharing" is not the most compre- 
hensive term to describe what actually is involved in a time-sharing system. 
Several concepts are integrated into such a package, including multiprogramming, 
on-line man-machine interaction, space-sharing, and parallel processing. 

Within the limits of the computer state-of-the-art, most of these techniques 
have been employed abundantly in the past, but not in a generalized, compre- 
hensive manner. The lack of an integrated, systematic approach has made on- 
line processing (i.e., program construction and debugging) too costly to 
consider for practical purposes, and has led to the use of "closed-shop" 
operation, with the evils of turn-around time, to maximize computer utilization 
efficiency. However, the concept of time-sharing permits „the computer to 
service several users in "parallel" such that the -slower human reaction time 
for each user may be utilized to service the others. In this manner, the 
computer will not be idle while waiting for a specific user to interract 
with his program, but is always kept busy with one of many on-line users or 
operating on a backlog of production jobs. The net effect is that each user 
will have the computer "continuously" available for his personal use. 
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A time- sharing system literally divides the computer's capacity among a 
multitude of users; computer capacity can be thought in terms of operating time 
and storage space. If the core memory is large enough, it may be space- 
shared between the current users. If it is a relatively small core memory, 
each user will utilize auxuliary storage (drums or disc) until his turn to 
operate brings his program (and data) into core. The latter method is 
referred to as a "swap". The operating time allocation is based on a slice 
of time, a "quantum", which is given to each user program in turn. User 
programs are operated in a queue, one quantum at a time, until the program is 
finished. "Finished" in the time-sharing sense means that it has run to 
completion (no more inputs expected), or that it has completed processing a 
laser's input and is awaiting further input. In either case, the user can 
teiminate his program operation at any time. 

Time-sharing systems require certain basic capabilities in software and hard- 
ware. The software aspects include an Executive control system, on-line 
program construction, debugging and Other service programs, centralized I/O 
operations, and an effective communication language to the system. Hardware 
requirements include efficient, human engineered input and output devices, . 
memory protection and relocation registers for the space-sharing of core 
memory, an interrupt system for inputs, timing, errors, etc., and large 
amounts of main and high-speed auxiliary memory. 

Time-sharing can be applied to any type of computer application, although if 
the area of application is too demanding (i.e., a particular program system 
requires too much core, operating time, and guaranteed immediate service with 
a high data-rate), then the computer capacity can be used up with nothing left 
to "share". However, a good time-sharing should be able to adjust from this 
worst case situation to more normal, sharable conditions. Among the appli- 
cations, for time-sharing which have already proven very effective, is the on- 
line construction, debugging and editing of programs. This approach has 
produced an efficient and economical way of reducing turn around time at the 
computer and increasing productivity. This is only one area of useful appli- 
cation, but one that is considered important for immediate implementation be- 
cause of the need to produce other "inhabitants" for the time-sharing system. 
Time-sharing, however, basically can be used for any type of program operation, 
and will not be limited to debugging, program code. Rather, the convenient 
"debugging" of formulation and ideas and the subsequent application of the 
results to useful data manipulation, reduction, and presentation is a major 
goal of the time-sharing concept. ' 

Initial System Constraints 

Problems always arise when a complex system is developed, particularly when 
design, implementation and equipment procurement are performed concurrently. 
TSS Model 1 is to be ready for use by July, 1963 , a* 111 this places time 
constraints on the effort. Many of the desirable features for the system 
will require more time for implementation or are dependent on hardware 
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availability. For these reasons, this document presents an interim descri' 
tioh of the cystem under the current conditions. 

The following li6t describes various hardware requirements which are preser 
not available and the effects of their absence on system operations. 


1. Additional Core Memory and 

High-Speed Auxiliary Memory (Disc] 


2. Peripheral Computer 


Memory Protection 


f and -I/O Traps] 


4. Relocation Register 


5» Remote Bulk Input-Output Devices 


[Paper Tape Readers, Printers, Etc.] 


6. Improved Typewriter Device 


7* Display Consoles & Light-Pens 


- Requires utilization of tapes 
permanent and temporary storar 
Slows down accessibility of p: 
grams and data, affects sched: 
priorities, restricts number c 
users using tapes, restricts 
utilization of larger invento; 
of programs and data. Also 
restricts total number of use: 
and magnitude of object progr; 

- Constrains the use of select: 
character interrupt, limits t} 
size of input and output mess; 
(TTY), limits the number of ue 
input channels. 

- Does not afford protection fo: 
the Executive system and objec 
programs. Does not protect a t 
illegal use of l/o. Does not 
permit security (classified dt 
protection. 

« Does not provide convenient mi 
for dynamic space-sharing re- 
locatability. 

- Does not facilitate large inpi 
or outputs at remote user sta: 
(e.g., for production runs). 

- Teletypes are clumsy, very sic 
and generally unsuitable for 1 
machine on-line intercommunici 
In addition, the character se- 
Inadequate. 

« (Display console output gene: 

• and light-pen inputs have not 
been treated in this document 
However, this problem area, a; 






















25 March 1963 


4 


TM-1126/000/00 


from hardware Implementation, 
1b concerned with priority 
aspects of scheduling. ) 


Since there is no guarantee as to precisely when equipment will he available 
for the system, the design of TSS Model 1 reflects currently available capa- 
bilities and existing constraints. As time progresses, various refinements 
in hardware and software will become available and appropriate documentation 
disseminated. 


Certain functions described in this document are marked with an asterisk (*). 
This indicates that the function may not be available until some time after 
July, 1963 or not completely definable for this document. These capabilities 
have been identified and, to a certain extent, designed, but may not be 
implementable within the next few months. 

II Description of TSS Model 1 



j 


.1 

i 



The time-sharing system has been designed to service many users in a 
"simultaneous" manner on-line . The system can also accept production jobs 
on a deferred- run basis. In the worst case, the system may operate only 
one large program (with priority). Thus the design encompasses a complete 
spectrum of possible environments. 

Within the time-sharing system, four levels of programs will be accepted. 
These are: > . . 

A. Executive System (overhead functions) - Level 1 

B. General Utility Programs (service routines) - Level 2 

C. Library Systems (large, special-purpose service systems) - Level 3 

D. Private Object Programs - Level 4 

The Level 1 programs will always remain in core memory (one bank of l6k 
registers). Some of the Level 2 service programs will also be kept in core 
in the Executive area. Level 3 may originate from drums or tape, and Level 
4 will originate from tapes. A further distinction between the four levels 
of programs concerns the processing of communication languages. The 
Executive system will process completely all Executive requests for Level 1 
functions. It will also partially process Level 2 (service) requests. 

Level 3 commands will be preceded by an indication of the service system 
(e.g., compilers) desired, and the further communications will then be for- 
warded to the service system for processing. Private object programs, once 
loaded and operating will also process their own inputs forwarded by the 
Executive system. 



i? 


I 
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A. The Executive System - Level 1 

The Executive System is the heart of the time-sharing system and is 
composed of the following elements, in addition to a central basic 
control sequence: ' • 

1. Interrupt Control - Responds to and determines source of operatic 

interrupts. 

2. Teletype Interpreter - Processes Executive commands and establish 

appropriate action by the Executive System. 
This function will also perform appropriate 
input legality checking. 

3 . Scheduler - Determines which user program will be operated and wl 

user drum to core transfer must be initiated. 
Permits user program operation for a " quant ur 
of computer time in its turn. 

4. Dispatcher - Assigns user storage on drums, tapes and core. 

Initiates all i/o transfers. 

5. i/o Package - Contains all i/o code and format conversion routi: 

and i/o transfer routines. 

6. Start-up and Clean-up - Initiates and terminates time-sharing 

;■ operations. 

In addition to the above named elements which are currently in pro- 
duction, it is expected that the following additional functions will 
added to the system: 

7. Recording and Accounting - Records pertinent data for analysis a 

• administration; raw recorded data is reduced 
. to more usable forms. 

8. Priority Assignment - Assigns priority indicator for user based 

on appropriate time and event criteria and/o 
by operator’s command. This function will b 
integrated with the Scheduler. 

9 . Library Maintenance - Adds or updates general-purpose rbutines 

a system library.. Also handles service syst 
library. 
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B. Service Programs - Level 2 

Service programs will normally include utility functions applicable to 
on-line program debugging. They will not be initially oriented to a 
particular higher-order language. The following types of service functions 
are being considered initially: 

1. Debugging Program - Will permit the examination and modification of 

object program code, and the controlled operation 
of the program for debugging. 

2. Dump - Large, off-line dumps of programs and data (initially, this 

will be octal). 

3. Tape File Maintenance (Symbolic) - Permits creation or modification 

of symbolic files on tape; includes add, delete, 
insert, print, etc.. 

Other Level 2 functions are under consideration for later inclusion, 
including text editing, timing service, trace, etc. 

C. Service Systems - Level 3 , 

Service systems are identified by language-dependent characteristics 

or by the magnitude or complexity of their operation. Compilers will 

fall into this category. At the present time, two such service systems 

are anticipated -'for inclusion in TSS Model 1. One is a special version 

of the JOVIAL one-pass compiler, JST, which includes a SCAMP compiler. j 

In addition, a special program to handle simple mathematical computations, 

. Calculator, will be developed. Other language systems such as IFL-V, t 

LISP, and ALGOL are additional possibilities for the time-sharing system. > 

I 

D. Private Object Programs - Level 4 I 

These programs originate from individual users and will be brought in ? 

and operated upon the command of the user. The procedures for operating | 

. Level 4 programs will be discussed in the next section. > 

TSS Operation and Machine Error 

The time-sharing operation will be initiated by the computer operator and 
will run until he "winds-up" the time-sharing period. If machine errors 
occur, it is anticipated that various startover conditions will be handled 
by the system. In some cases, the users may have to reinitiate their 
operations . 






I 
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III The Initial Executive Command Functions and Language for The ARPA-SDC 
Time-Sharing System (TSS Model l) 

The initial phase of the AKPA-SDC Time-Sharing System will require a mi: 
basic set of commands whereby potential users can communicate with the 
Executive program in the computer. It is intended that the initial set 
commands, called Executive Commands, will permit adequate communication 
facilities for the Time-Sharing control system without extending the 
sophistication of the system to a greater degree than necessary for the 
first developmental phase. 

The concept of man-machine communication which will be pursued for the 
Time-Sharing System will provide the capability for the Executive syste- 
to recognize and react to those commands to which it can be expected to 
respond. Other communication, destined for object programs and service 
systems, will be passed on by the Time-Sharing System to the specific u 
program being operated. Thus, the Executive system will not be respons: 
for "understanding" all types of languages, and, to minimize system ove: 
head time, the Executive system will not examine the user's communicati 
unless it is specifically identified as an Executive command. 

The initial set of Executive system commands will be adequate for pract 
operation of the Time-Sharing System. However, the list is open-ended 
that additional commands may be added as necessary and the system respo 
to particular commands may be modified as the need arises. 

The commands bear several characteristics which lend themselves to prac 
use. The words will be short in the number of characters they contain, 

• readable, and will be hopefully unambiguous. Finally, no two commands 
be similar enough to make the command still appear legal if a typograph 
error occurs. In composing the Executive command message, the specific 
format order must be followed, with at least one space between paramete 
fields, although excess spacing between message fields (including carri 
returns and line feeds) will be ignored by the Executive system.' 

A. The Executive Command’ Identifier 


Executive Commands will be preceded by a special character to ident 
it as such. The special character has been selected for the model 
Teletype as the exclamation mark (.'), an urroer case character. The 
Input Interpretation portion of the Executive system will process t 
commands preceded by this symbol as Executive commands, if there 1 
no such identifier, the command will be passed on to the user's obj 
program (or service system); if no object program exists to receive 
a message, the command will be rejected as illegal. The (.')'can be 
to communicate with the Executive even while the object program is 
operating in order to perform various service or debugging functior 
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B. End-Of-Message 

All teletype messages to the time-sharing Executive system must conclude 
vith an "end-of -message" character. (This does not necessarily apply to 
service routine communication.) The character is the "Bell" on the 
A-28 teletype. Object programs vill have an initial option of using 
the Bell character, or interrupting on every character. 

C. Executive Command Response 

Executive commands will "be used to communicate directly vith the Time- 
sharing System. This includes any portion of the overhead system 
(level l), common service functions (Level 2), and initiation of Level 3 
and b programs. The commands will be, e xami ned as rapidly as possible 
by the control programs but response to these commands vill be dependent 
on the nature of the request and the current user load on the system. 
(The scheduling algorithm vill h andl e the queue of user requests.) 

A positive response to every Executive Co mman d vill be given to the 
user in one of the folloving forms, folloved by a carriage return and 
Bell. 

(1) , $ WAIT - Request being processed. 

(2) $ BUSY - System operating at maximum user load, or a particular 

service function is currently in use and it is restricted 

to one user at a time. 1 

(3) $ ILLEGAL REQUEST - Format or contents of command in error (vith 
. X “ indication of specific error). 

(4) $ READY - Command has been executed. 

(5) Line Feed, Carriage Return and Bell. 

The user should wait for a response from the system prior to inserting 
another request, unless otherwise specified. This principle applies to 
most on-line programs . All system printouts vill be preceded by a 
special identifying character. This character vill initially be the 
dollar sign ($). 

D. User Identification 

The Time-Sharing System will permit a variety of users to gain access 
to the computer. However, it is desirable that the possibility of 
confusion over the identity of specific users be reduced to a minimum. 
This is especi ally necessary where several users will queue up on a 


9 
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Single input device. For this reason, TSS Model 1 will require use 
identification for certain Executive commands, rather than assume t 
the same individual is still using a given teletype channel. 

To minimize the user's identification function, an initializing LOG 
command will he used at the beginning of each user’s operation. T3r 
LOGIN function will accept appropriate reference information as to 
user's organization, man number, work order or problem number. In 
return, the Control System will generate a temporary user's referer. 
number to be used for the duration of his current time-sharing opei 
The reference number will be used for those commands which indicate 
new operation being initiated by the same user. This procedure wi3 
require the user to always "register at the front desk" prior to oj 
ting and thus guarantee correct, bookkeeping of user activity. 

E. Deletion of Executive Command Entry 

If an erroneous Executive command (no end-of -message character' incl 
has been entered on the teletype, it may be deleted by- entering tin 
(or more) line feeds in succession, followed by the end-of -message 
This will cause the Executive System to disregard this input, and 3 
back to the user, "Cancelled." If the last command entry containec 
. end-of-message character, the QUIT command or CANCEL instruction c( 
be used. 

F. Sequence of User Commands 

To initiate a time-shared operation, the user will first note any 
printout on the input device regarding the current status of the 
Time-Sharing System.. Notices will be generated to all stations wh< 
the system goes on the air, off the air, or if portions of system 
capability are temporarily unavailable. This information will be 
generated each time a user teletype channel becomes free for the n 
user on that channel, or when a significant change in system statu, 
occurs. 

0 

1. LOGIN 


Assuming that the Time-Sharing System is on the air, the user • 
type in the following Executive Command: 

J LOGIN ORGANIZATION CODE USER'S NAME WORK ORDER NO. 

(Last and initials) or 

or PROBLEM NC . 

MAN NUMBER 

The organization codes will be specified at a later time. 
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The system will respond with a busy signal (BUSY) if unable to 
accept a new user. Otherwise, the printout will indicate READY. 

At this point, the user may enter into the system any external 
symbolic data or programs by creating or updating a "file" on tape. 

A service function (Level 2), the tape file maintenance program, 
will be available for this operation and is discussed later on in 
this section. 

2. LOAD 

In order to operate any binary object (Level 4) program, the following 
command will be used: 

User's Ref. Object Program Tape Reel (End-of-Message) 
No. Ident. No. 

.' LOAD XXX AAAA XXXX TtKT.T. 


I 

i 


The LOAD function will cause the transfer of the specified binary 
object program from tape to drums (if not there already) in pre- 
paration for on-line operation. If the program is not in the 
.system (core or drums), the system will search the tape drive 
inventory to locate the specified reel number. If the reel number 
is not found, a request will be generated to the operator to load 
the designated tape reel onto a given tape drive. When the operator 
has loaded the reel and so informed the system, the program will be 
• - transferred to drums and a message sent to the user saying LOADED. 

If the indicated tape reel cannot be located by the operator, he 
will notify both the system and the user of this fact, and the 
LOAD request will be automatically cancelled. 



If the object program will use tape or card inputs or outputs, 
these will be identified in the LOAD command an follows: 



(Inputs) 

(Outputs) 


Reference No. Tape Reel . 

For Object Program No. (Deck 

Identifier) 

II XXXX 12 XXXX 13 C AAAA, etc. 

01 XXXX 02 S 03 B Oil L 05 P, etc. 



S will indicate a "scratch" tape (no particular reel number, and 
not to be saved after operating). B will indicate an output blank 
tape is needed, which must be saved. The system will then inform 
the user (and operator) of the tape reel no. and file name for future 
use. L will Indicate an output tape to be listed after completion 
of the operation. All output tapes (0, S, B, & L) will be mounted 
with the file protection ring on the reel. A "C" following the 
Input identifier means the card reader, and a "J?" following the 




25 March 1963 


11 


TM-ll 26/ 


m 



Output identifier means the punch. These must he available i 
use as indicated by the computer operator to the system. In 
case of the card reader, the specified deck must be loaded as 

The operator procedure to load required tape reels (and card 
described earlier will apply to all tape needs of an object j 
If for any reason, the tape reels or card deck cannot be loac 
or the i/o equipment is not available, the request will auton 
be cancelled, with a printout of "$ BUSY". 

If the object program will communicate with more than one te] 
channel (multi-user interaction), the participating channels 
identified as follows in the LOAD command: 

Ref. . TTY 

No. Channel No. 

T1 XX T2 XX etc. 

(This is not applicable to the situation where the object prc 
normally communicates with only one user, but several users n 
provide the inputs and copies of output are sent to all obsei 
users. This capability is obtained by using the ASSIGN cornu 
later.) 

3* . GO 

Once the user's object program has been transferred to drums 
(and required tapes mounted), the system will print out "$ RI 
The user can then initiate its operation by the following cor 

^EOM) 
l GO BELL 

/ 

This instruction will cause the program to be transferred to 
and control branched to the program's starting location when 
user's turn in the operational queue arrives. 

The object program will operate until the user takes a termir 
action, it is automatically suspended because of user inacti\ 

. (no TTY inputs when inputs are expected), or the program runt 
completion (does not expect input), (if a user initiates a 1 
LOAD request on the same teletype channel, this will cause a 
suspension of the current program operation. ) 
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k. STOP 

The user may "halt" his operation at any time hy giving the STOP 
command, using only the ! and Bell. 

(EOM) 
l BELL 

This command will retain the object program and environment in core 
(as long as possible) but will not operate it. At this point, the 
user may examine or modify portions of the data or the program he is 
using via Level 2 service functions and continue if desired. 

(See Resume below.) 

5.' QUIT - Q 

If the user wishes to permanently cease his operation and is not 
concerned with preserving the program environment, he will issue 
the following command: 

(EOM) ■•> >. 

Q BELL 

The user's program and environment will be erased from drum and/or 
core, and the teletype channel will be made available for a new 
user' operation. 

*6. DEFER 

if the user desired to temporarily suspend his operations within the 
time-sharing system, he may issue a Command which will deactivate 
his program and save both program and environment for later restart 
from the last point operated# The command for this function is: 

• defer bell 

This command will cause the Executive system to place the indicated 
program and its environmental data on a tape. The tape reel no. 
will be given as output to the user for future restart operation. 

The D EFER co mman d should not be used for object programs using tapes 
or cards , 

7. RESUME 

Programs which have been stopped or deferred by the user can be 
resumed from the point of last operation by using the following 
command: 


t 






ii.syfttwyMUv r g - .r*’- 
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Tape Reel No. (EOM) 
RESUME XXXX m.T. 


(The tape reel no. must be given if the object program is no 1 
in the system. This will initiate the tape load function. ) I 
program is to be restarted from a location other than the last 
of operation, the new starting address (relative) may be indie 
in the command as follows : 


Relative 
Octal Address 
RESUME XXXX 


Tape Reel 
No. 
XXXX 


(EOM) 

BELL 


The RESUME command cannot initially be used for object program 
using tapes or cards. An initial restriction will be placed o 
user in that he may defer only one run of the same program at 

*8. CHANGE . 


The user may make limited changes to a prior LOAD command with 
respecifying the entire original request. The command CHANGE 
permit the addition or replacement of LOAD parameters (tape re 
numbers and identification of input, output or teletype channe 
reference numbers.) 

.. * CHANGE AAAA XXXX BELL - indicates desired binary program 
- indicated tape reel no. 

• CHANGE II XXXX 01 XXXX BELL - indicates revision (or add: 

in identification of tape input a 
output for object program. 

.' CHANGE B 13 XX .BELL - . indicates an additional blank tape 

object program, and XX is an addi- 
participating user channel for th: 

The CHANGE command may be issued after the user receives a "WA1 
response from the system, but cannot be given after the GO com: 

9. ASSIGN 

An object program, which can communicate with only one user, ms 
observed during operation from more than one teletype station : 
the use of the ASSIGN command. This will permit multiple copis 
all inputs and outputs to be sent to observer stations. (This 
situation does not apply to object programs which are designed 
communicate with several users.) 
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Teletype 

(EOM) 


Channel No. 



.' ASSIGN XX XX XX 

BELL 



Inputs to the object program can come only from the teletype station 
•originating the LOAD and ASSIGN commands, (it may be possible in 
the future to minimize this restriction.) 

*10. CANCEL 

To countermand the last Executive request inserted into the •.system., 
if appropriate , a CANCEL (Level 1) command can be giveh: 

(EOM) 

: Two Line Feeds BELL 

This will permit an object program to continue operation, but will 
cancel any Executive service which has been requested concurrently 
(if possible). 

11. DIAL 


A. service which will be provided by the Executive system (Level 1) 

Will permit the use of the teletypes for direct station-to-station 
communication. With the current computer configuration, the length 
Of a teletype communication message is limited to a total of 9 6 
characters (including all control characters such as upper and lower 
case shifts, line feed, carriage return, and end-of-message.) It is 
suggested that about 88 printable characters (including spaces) be 
used as a rough limit on the size of the DIAL message. 

The DIAL command may be entered into the system at any time during 
the user's operation, as long as the system has acknowledged the 
last prior input. Once the DIAL input has been entered, no further 
Input shduld be given by the user until the service has been completed, 
since that input may be partially destroyed by a new message. The 
DIAL function will be performed during the Executive System's over- 


head time.. 


(Addressee) 

Start of 

Teletype 

Message 

Channel 

Indicator 

i DIAL XX 

Line (Message) 

* 

Feed 


Multiple addresses may be given, with an initial limit of three 
teletype channel addresses. 

. J DIAL XX XX XX Line (Message) BELL 

Feed 
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When the DIAL message has been transmitted, the system will pr; 
to the sender: 

$ DIAL COMPLETE 

FIND 

The Executive system will provide information to the user conce 
the. drum and core location of his programs and/or data. The FI 
command may be given after the object program has been loaded \ 
system. If the program itself declares a drum storage file, F: 
must be used after the program has started to operate. The pr: 
will give the assigned core and drum storage, the current queue 
and tapes being used by the object program. 

.' FIND BELT, 

RUN 

Although the prime customer for time-sharing services should be 
programs which interact on-line with the user, it is recognizee 
that a great deed of production work must also be processed by 
system. By definition, a production run will have an inputs t 
outputs specified prior to the operation, and no user inputs 01 
interaction are expected during the course of the run. The pre 
duction run also implies that the user does not nor mally requi: 
system response time necessary for on-line interaction, and th\ 
it may be deferred until convenient for the system. 

The RUN command must be instituted with all required inputs lot 
for system use. Thus, any symbolic data should first be "filec 
to tape. The RUN command will contain a~i i the necessary inforr 
for operating the object program; it will be preceded by the uf 
LOGIN function. 


User's • Object Tape 

Ident Program Reel 

(Ref. No.) Ident No. _ . 

' Card 

RUN XXX AAAA XXXX Deck Ident 

II XXXX 12 , XXXX 13 C AAAA etc. 

01 XXXX 02 P 03 B etc. 


Estimated 
Run Time 
(Minutes) 
XXXX 


Normally production run outputs will not be transmitted to tele 
However, bulk output to remote locations in the form of punchec 
paper tape or high-speed printouts may be available in the fut: 
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Production runs may be submitted through the operator, who will enter 
the RUN command himself. 

Production run outputs will be produced on tapes, which can then 
be used for printout (or possibly card or paper-tape punching), or 
for subsequent program input. Output tapes are identified as L 
tapes in the RUN and LOAD commands. These tapes will be printed out 
and then blanked. If they are to be printed and saved, they will be 
identified as normal output tapes, either 0 or B and the user will 
inform the operator about printing the tape off-line . 
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G. Service Commands - (Level 2) 

Hie Executive system will process user commands which call Level ; 
functions. Level 2 programs fall into two classes; Class A progrf 
(e.g.. Debugging Program) are permanently available in the Execut- 
area of core memory, will not use tapes, and will operate on progi 
(or data) located in core memory or drums in small intervals of f 
such that the input -to -output process will be complete within one 
quantum of system time; Class B programs are service programs whic 
US JLw PeS SQd may not necessarily complete input- to -output o~ 
ation within one quantum of time. The inputs to Class B programs 
not have to be located in core memory prior to service operation. 
Furthermore, Class B functions which tie up tapes will initiallv t 
one user at a time. (This will be discussed later on in this sect 

In addition to the above-mentioned Class A and B programs, a third cle 

,^r U ^ eS — i» constructing object pro^s 

using library subroutines. * ^ 

Reversion , 

It is anticipated that Class A debugging routines may be employed 
| nt ermittantly during object program operational checkout 
Thus, it is desirable that the process of alternately operating ar 
debugging be facilitated as much as possible. This will be accomr 
by- automatic reversion" of the user’s operating status from a Lev 
. 2 operation (debugging) to the previous operating status of his ob 
-• program. Class B routines will initially be treated similarly to 
Class A routines as far as reversion is concerned. 

In the light of the reversion concept, it will be necessary for th 
user to place his object program in the status desired after servi 
operation prior to using the service functions. For example, if 
several different service operations are necessary prior to contin 
operation of the object program, the user should STOP his program 
After service, it will still be in the STOP status. 

Class A Service Functions 

a. Debugging System 

Programs which have been compiled but not checked will req 
of a debugging tool which operates on-line 
within the ^time- sharing system. The concept of on-line de- 
will vary from present debugging procedures. Accordingly 
set of debugging routines, operating through the Executive 
system, will be developed for TSS Model 1. The debugging 
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service will allow the user to examine any address in his program * 
(or data) in a specified form, i.e., octal, decimal, BCD, symbolic. 1 
The contents of these registers (core or drum) can then he 
changed. The program or data may he searched for particular 
values, address references, etc. Breakpoints can he inserted 
within the program and the program may he operated from any 
appropriate starting location. In addition, the contents, at 
any point, of the machine registers (accumulator, B register, 
logical register, index registers, etc.) can he obtained hy 
the user. 

A concise communication language utilizing the available key- 
board character set is being developed to control the debugging 
package. Initially, the language it will handle comprehensively 
will he machine language and appropriate aspects of SCAMP and 
JOVIAL ( JST) . 


This service function will provide the user with an accounting 
of his time and space utilization up to and including the 
final COST command. 

User Ident 

Ref. No. (EOM) 


f CD I 


2. Class B Service Commands 

a. Tape File Maintenance Functions 

Symbolic information (programs or data) will he maintained on 
tape in sequential line number form. By referencing the 
appropriate line number, tape files can he modified and updated 
through the use of appropriate file commands. 

Due to the fact that the initial TSS is tape-hound and tape file 
maintenance requires tape access, these functions will he 
available to only one user at a time. At the time of request- 
ing this service, the user will he notified of three possible 
conditions : 

(l) "jjjREADY" - user may proceed to use the tape file 
service. 


(2) "^RESERVED" 


service program in use, but user will 
operate next. ("READY" will be printed 
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out when user can proceed.) If • 
does not want to wait, he may is 
a "QUIT" command. 

(3) "$BUSY" - service program in use and anotht 

is next in line. User may try a t 
later. 

(1) FILE - F ■ 

This command will create a new symbolic tape file, and w: 
require loading a blank tape by the operator. 

File game Tape Reel • Input 
No . Source 

' ! F AAAA (XXXX) 1, ' C . Card Reader 

, Blank = Teletype 

Inputs for FILE will be expected from the teletype channt 
u nl ess specified as C in the command. The user's identii 
for LOGIN will be used to label the tape reel, nnri the re 
number will be output to the user upon completion. The I 
input to the FILE routine will be an END message or card' 

(2) UNFILE - FU 

1 Itlis command will notify the operator to blank a designa-t 

tape file. If multiple files (belonging to one user) are 
maintained on a tape reel, this command will mark the fij 
for later deletion. 

File Name Tape Reel 

•— ^ No. 

'• ! FU AAAA XXXX BELL 

(3) REFILE - FR 

This command will accept a number of file updating instru 
from TTY and perform the specified modifications. When 
completed, it will UNFIUS the old file and print out a nt 
tape reel to the user. 

File Name Tape Reel 

No. 

jra aaaa xxxx TffiiT.T. 

The designation of a particular tape reel number is optional. 
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When the system responds with a "tRWATw 4 ' a 

may insert the following inputs: printout, the user 


Action 

Code 


(a) r 


(Symbolic Entries) 

XXXXXX 
XXXXXX 
XXXXXX etc. 

(Line number) 


(Line number) 

XXXX 

XXXXXX 

(symbolic entry) 

(Line number) 

XXXX 

XXXXXX 

(symbolic entry) 


ADDS following symbolic 
entries to end of file 


Deletes indicated line 
no. entries 


Inserts following symbolic 
entries after indicated 
line no. 


- Replaces indicated line no. 
with following symbolic 
entry 


3^ ? he servl<!e 

action code) may be fraSmittSd 168 i? 0t lncludln g the 
inputs will be caned^r^i f ? ° ae and further 

will be separately a Sne feedS? f ° f Entries 

of an inpS can ^ ? el J tl0 " 

and the end of message (BELL) This wt 1 1 line feeds •• 
to ignore that input. If a prevSs S™t T*®* ^ p , rogram - 
a new input will override the previous Xe. Ranged, 

FILE MERGE - FM 

« £ *r *• 

may be involved at one time/ 6 ’ N ° than ^ ^ reels 

Se Kama File *ame SS Ko. ». 

! IM ASM SAM m ASM XXXX B] 

“* rMUltlnS fUe *" « — for the combined events. 



I 



'oo 

>1 

* 

. 
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(5) FILE PRINT - 

FP 





\ 

All or portions of a symbolic file may be printed out on 
teletype or offline with the FP command. 

■c 



File 

Name 

Tape Reel 

No. 

Offline 

Indicator 

Starting End 

Line No. Line 




I FP AAAA 

xxxx 

, (0) 
(optional) 

XXXX XXF 


! 


If the entire file is to be printed out, or where the rer 
of the file from a given starting location is to be print 
the letter A will be used as follows: 

.>11 c 
ed 

m : ' 

1 -.r&i-. - 

i ■ • 

• 

. File 

Name 

i FP ■ AAAA 

Tape Reel 

No. 

XXXX 

Offline 

Indicator 

Lot' ) 

( 0 ) 

A BEI 

ne no. 

•f r% 

i 

l FP AAAA 

or 

XXXX 

• Starting 

Line no. ■ 

(0) XXXX A BEL 

a. 

i 

t. 

mt:: 

■■ 

Delayed Dumns 





Large dumps, which are not practical for on-line teletype 
printout, can be specified for printout off-line. However 
this capability will be initially limited to octal printou 


DD 


Relative Address 
of Starting Location 


XXXXXX 
May be given 
in octal or 
symbolic tag 
references 


No. of Registers 
to be dumped 
in decimal 


XXXXX 


BELL. 


If a drum file is to be dumped, the drum file name used by 
object -program must be given. i 


DD 


Drum File 
Name 


. AAAA 


Relative 
Start ' 
Location 

xxxx 


No. of 
Registers 
In Decimal 

mx 


BELL 
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Delayed dumps may he called for at any time during the user's 
operation. However, only one user at a time may^sf^s service 
nd there may he a wait until the function is available. All * 
delayed^ dumps will use the same output tape for ease of operator 
tape maintenance and to conserve useahle drives. Each delayed 

tZSJSJSE?* " ser ’ s ^ 


\ml- 


j m : 

I (!'i !"'[! 

1 5 ti 


It is anticipated that the system he self-explanatory to the 
user, in that guidance or how to use the system and what it 
can provide may he shown to the user upon request. The EXPLAIN 
command will be a service function vhid, proves "auSLSS^ 
documentation on procedure and inventory availability. The 
initial command; “ 

(EOM) ' •, . ' 

i EX BELT. 

^ Te a printout of available explanation of different 
subjects, (e.g., ^"Executive commands, service functions. Dispatcher 

inSiZSiH' Tbe . UBer can then seiect the subject code 

indicated and a lower level of selection will be offered. 

>. ^ the user.^ ** f0llowed aB deeply as required (or available) 

Service Systems Commands - Level 3 


^®®r SCal f servlce factions require a great deal of developmental 
effort, and consequently only a minimal amount of Level 3 products will 

b Lf™ llable for TSS Model 1- However, with the passage of ttme oSS 
additions will be made to the system. ^ 6 me ' 0ther 

LL , be ln ^ tiall r called in with an Executive command, 
y8ten 8 ready for the user ' 811 father inputs will be 
serv l ce extern's language, until another Executive 

they wilAsuIlly be^TOilable^to 

SSL W5 

1. JOVIAL - JTS 

of JOVIAL one-pass compiler will be available for the 

SdswS ae ^ S r tem ’ vf 6 Wil1 accept symbolic inputs from tape (and 
cards) and produce a binary program on, tape for subsequent use in 
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the time -sharing system. The symbolic deck should normally be 
on tape prior to giving the following command: 


AAAA' 

XXXX 

D 

Optional 

E 

Name of 

Tape 

L 

error output 

symbolic 
file = 

reel 

of input 

N 

on teletype 

name of ■ 

file 

D = 

Detailed listing 

object 

or 

L = 

Straight listing 

program 

C = Card 

N = 

No listing 


Reader 



initiaT comlr.r IUrtner control inputs other than the 

If arG used ' the °P e ration will be hand 

by the operator, as described for LOAD. 

Son^th 0 ^ 1 ^ 1011 iS , COmplete ^ a P^tout will indicate thi: 
aiong with the tape reel no. of the binary output. 

JTS can be operated in the production (deferred operation 1 ) mn*< 
mming the JTS as the object program ii the"S S 
tape reel number, in this case, will be omitted. 

The. detailed operation of JTS will be described in other docume 
2. SCAMP - (JTS) 

■' the «»e-sharlng eysten viol be availabl 

a the JOVIAL compiler. The symbolic input file will contain 
appropriate indication- that' direct code will follow and if Si 
„ e C ^ 1 ^ ed P r °Perly. ' The same Executive command and parameter 
for JTS is applicable. Further information “eSomSSS 
languages will be documented shortly. : 

*3* Calculator - hata 

A program which will perform simple arithmetic comoutationR lh n 
be developed for the tlne-sharir5 system. It «?SSte if i 
manner similar to a desk calculator; At preseS, thfSniS 

oa “ ot specified, but till be documented in the fut 
(tolculator nay be a level 2 function, residing permanently £ 
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This section will deal with the manner in which object programs for the 
time-sharing system will be designed and coded. It is not possible to 
furnish all the details at this time, but as they become available, they 
will be appropriately documented. 


A, Concept of Time -Sharing Programs 

Programs which will operate on-line in a time-sharing system should 
possess several^ inherent characteristics. They should hopefully be 
small, fast and^operate on mini ma l inputs, they should minimally 
involve the use of tapes, and they should be capable of communicating 
with the user via the teletype. In addition, all I/O functions will 
be performed by the Executive system, and thus a centralized I/O 
package will be utilized by all object programs. 




Object programs, which will be generally useful for service to several j 
independent users, should be designed as "pure" programs. Conceptually, j 

pure programs do not modify themselves in any way, and all specific j 

user references are maintained in associated tables. With this techni- 1 
que, programs may be interrupted at any point for a given user and I 

resume service for that user at a later time. This will permit one v 

program to service several users without replication for each one. ' 

Generally speaking, however, programs of this nature will probably 
not be Level 4 types, and will be part of the service system. 

Initial Priority Considerations for Time-Shared Scheduling 

In TSS Model 1, the scheduling function will discriminate between 
small and large programs and programs which use low-speed I/O and 


Undoubtedly, object programs cannot all be small, since the magnitude 
of problems which can benefit from time-sharing may be large. Pro- I 

grams large and small can always be run in a production mode (RUN) . I 

However, one must remember that there is always an upper limit on K 

the capacity of the system which could be completely used by one t? 

object program, leaving nothing to share in a practical sense. The ft 

time-sharing system will be geared to handle a worst case, with fl 

appropriate limitations on additional users. s' 

■ . r^- 

Programs which are to interact on-line with a user should optimally ft 

reply to the user's input in accordance with the user's response f§ 

time needs. Furthermore, since this is a two-way communication situ- k< 

ation, the program should provide appropriate positive responses to f 

each logical user input. That is, the object program should control 
the user's input rate, if necessary, by providing pertinent feedback 
for more input. 1 ■ 
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those which do not. The three categories which exist are listed : 
the order of precedence for systems 

1. No low speed I/O (card reader, punch, tapes), and 
size less than l6k (including table space) 

2. No low speed I/O and size between 16k 32k 


Low speed I/O and size less than 32k 

3. Program size exceeds 32k 

The Scheduler will determine the priority of a program from the LC 
command which indicates input and output needs (i.e., II, 12 01 
L, etc.). Programs of higher precedence will be serviced prior tc 
those of lower precedence. 

Production Runs 

Programs which are initiated with the PUN command will be operated 
only when no on-line programs require service (i.e., waiting for 
input). When they are operated, they will run. to completion (or 
.estimated running time) without quantum interrupts, unless on-line 
users interrupt for service. Programs which are checked out and 
available for production runs will be maintained on a production 
library tape. Level 3 service systems may also be used for produc 
purposes by giving the BUN command and identifying the service sys 
(e.g. , JTS) as the object program. 

Program Identification 

Programs to be operated in TSS Model 1 will have their identifying 
tag names limited initially to four alphanumeric characters, not 
including modification numbers. Mod numbers may not be necessary 
for program maintenance in the system, since only one valid versio 
of a particular program should exist. If versions differ function 
ally, then they should have a variation in the name. However the 
is no restriction on how the identifying characters are used/ (Sy 
programs may adopt a unique identification character in the future 
which may not be used by object programs ) . 

The reason for limiting the ident to four characters is because of 
equipment constraints; for reading a tape by ident, only four 
characters are used. 
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Programming Lan g uages and Compilers for TSS Model 1 

olit ? lae of the 183 be used la It 

Sdition Se th the DiSPatCher Ca ^ se ^ 2 i a iS e i/ 0 S activities t ° 1 ?°’ 
^ tap “eHy t L^t by ?, epeclal *"««“ 

&srr A s^ e cs d 

for P 5 i^Tf^ch ° t “' Pa ^ ° 0mPller 1S b * lo « ««*«, 

by the system. lie pane of this co.-^lLS'S' js? STit^f?* UM 
card or tape input. In addition to -f it will accept 

SCAMP codef el£ a, mu?Ti»Sl be “^ble ° f «*»Ulllg 
In the latter case the spamp * a0VIA1, P r °eram or entirely in SCAMP. 

JOVIAL direct Se’hr^hetT SfnTof VSSt 

detail shortly. A current W f P “ *5 be documented in 

©I-970/002/OO JOVIAlS ? S t 8 pertinent is 

Compiler ’ ^ ^n^age of The One-Pass JOVTAT. 


Compiler . # ^ i*mguag e or The One-Pass JOVIAL 

One problem which exists is the incompatibility of 

stants between J -2 and the -present scamp mjL , Ho ii e rith con- 

sortable Hollerith whereas J-2 does.^° a re” it ^ t J anslate into 
•for the Dispatcher to be aware of th P fv^+ S + v111 be necessary 

being used Ld consiirat^L beS^ g“en^f Ss^^ 18 
mode. A procedure involving the Dispatcher calls is - m 

M of 8ortatie ° r «&-*£ c^e^s S'sf 

Program Size and Data Tables 

Ssss h f 8tOTaee 

expect svt™ ^seir and the maximum amount of data it can 

Programs may de Clare' ^vSTfile^e cl re ° arve f by declaring dummy tables, 
on Suns MS g" 

seSS? Ir08ra " 8U,,B8ts Input-dependent IZts^nl S‘“ 
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F * Programming for Teletype Communication 


prograIn * for the -ime- sharing system will intercommunicate 
?\? L US8r Via telet ^ es initially . The use of display scopes 
and light pens vill he treated in future documentation. Until a 
peripheral, computer becomes available, the input memory and outpu: 

bU £f e f drum Y 111 used for in "- out teletype activity. These plac 
certain constraints on the object programs in the system. 

1. INPUT 




Input memory space vill be allocated among the av ailab le tele- 
type channels, resulting in a maximum figure of 160 characters 
^20 words) for the total number of characters (including an " 
control and non-printable characters) -which may be entered by 
the user at one time. The current means of "transmitting" the 
input to the system is either via an end-of -message (Bell) 
character, -which vill generate an operational interrupt in the 
computer, or the object program can specify an interrupt on 
every character. This vill cause the Executive to convert and 
examine the teletype code. If the message is for an object 
program, it vill be stored in input memory until the object px 
gram operates. At that time, the message vill be transferred 
tlle designated File area in the object program’s core spe 
(For character interrupt, all Devly arrived (and converted) 
characters vill be transferred. ) Normally, the user should ve 
for a positive response from the object program prior to enter 
another message, unless otherwise specified. 


The object program when ready for a new input massage, must me 
a call to the Dispatcher, The normal procedure for teletype 
interraction is for the object program to generate an output 
and -wait for an input. For this purpose, there may be a conve 
method for an I/O call to combine a teletype output call with 
subsequence input call, eliminating the need to return to the 
object program in between. 


Another feature is the "no-vait" option. In this case, an I/O 
call for teletype input nay be made, but the object program vi 
continue to operate. When an input from the teletype arrives 
it will be placed in the "file" area of the program before the 
next quantum of operating time. It is not advisable for the 
object program to use the same "file" area for both input and 
output messages, especially in the light of the above procedur 


Procedures must be established by object programs to cancel or 
delete a current input or previous input. The Executive syste: 
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SSf 5 0r “ 0re line feeds for this, and it may he 

eful if all teletype characters are normally valid input/ 

2. OUTPUT 

' iSo 6tyPe ° U ? pUt ma stages may be generated at any time by the obieet 
' **F na > f in * “ VO call to the Dispatcher. aJ ^e^oOTamkwili^ eCt 
Thp S G ? ate U ? til the messa S e h as been output to the teletype 
Bie maximum size of an„output message is 12 words or 96 chScters 
including all control, non-printable characters Shn-r+or- 8 * 

vith’an “IT” 

the maximum size output message, the waiting time will be at 
least l6j£conds before the object program can^Ste ^ain. 

An object program using the teletype should consider initializing 
the teletype for the user prior to his next input ThS nSmS 

r , 8 8 ° a li^e feed, carriage return, and BELL.- Un- 

ortunately, this wUl leave the^nachine in the upper case but 
the end-of-message (Bell), which must be last, is^Lr case 
This may make things inconvenient for the user to fSst go to 
lower case before typing in an input, (it is fine for Vrom+i 
commands which start with an uppercase ^cha^acte^O )!) 

General 

•She Dispatcher calls consist of loading the accumulator *rf+v> +v,~ 

S°S‘ 8 ° f the table —talnA the 

and branching to an absolute address in the Dispatcher. This 

ISTeSSt SI?”® ^ instructions 


DIRECT 

Assign A = PLACE $ 
BUC 312 » 

JOVIAL 


(PLACE is an arbitrary item which 
has been set to the LOC of the 
calling table.) 


For the new JST compiler, the references will be easier. 

DIRECT 

DDA CALL (CALL is an arbitrary table uni.. 

BUC ™ wnere the I/O calling parameters 

312 * are contained.) 

t. 

The above procedure is also applicable for file declarations 
Eventually this function may be incorporated into more convenient 


ST3E?»r^. 
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library procedures. The actual parameters are described ir 
section entitled. The Use of I/O . 

4. Future Developments 

When the peripheral computer becomes available, many of the 
straints indicated above will be removed. In addition sir 
character interrupt will eliminate the need for an end-of-m 
(Bell; unless so desired. It is anticipated that an object 
gram may initialize the peripheral computer to interrupt on 
specific set of characters or all characters by means of an 
initializing call to the system. 

If other input devices become available, the character set 
change with appropriate implications for the input and outp 
processing conventions. Also, the general needs of object - 
grams for input scanning and output message composition may 
serviced by convenient library procedures. 

G. Normal Exits of Object Progr^™” 


Programs which will operate under time-sharing should never com 
a halt. Two exits will be available,* the first exit is to the 
Executive system, indicating conplete termination of its operat: 
the second exit is to the Dispatcher for new teletype input. I; 
addition, programs will exit to the Dispatcher whenever any i/o 
. action is required. 

If an object program (on-line) hangs-up in a loop, the user sho'. 
be aware of any excessive response time and stop the program fo: 
analysis. A halt in the program will generate an error int erru] 
this will cause an error message to the user. Production runs s 
be operated according to the estimated running time indicated 
the user. When that time elapses, the operator will be notified 
and the program discontinued. (The procedure may allow operato: 
control to continue the run, ) 

The exit addresses to the Dispatcher and Executive will be publ - 
at a later date. 

H. TAPES 


Tape Formats 

In general, tape inputs used by an object program are not re 
stricted to any particular format.- However, large tape recc 
should not be used, so that data transfers can operate with 
smaller units of I/O time for time-shared, on-line operatiox 
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Tape Reel Maintenance 


Tape reel maintenance -will he a problem for the system and not 

SESf* SOlVed ‘ For the time foli^Sg^ape 

utilization proceaures -will he followed? p 


levels 1. 2, 


Level ij. 


(level 1 , 2 , & 3 ) . will he on special tapes 


ggbolic Tape Fi les - will he normally maintained on a single 
tape for each user, unless the user desires his files on separate 
tapes. Updated files will be -added to the end of ta^LToSSete 

=5Lsrip“ or aeletio “- <A * aam tiM > ^ ete 

■ unchscted-out - *11 bo place# on Individual 

* MS 5 SL^L Q .S^ama - checked-out - will he loaded on a communitv 
xape unless specified otherwise. The procedure for this ^ 

on S thin°+ Vl11 te defined Bama time in the future. The programs 
on this tape can he used for production or on-line operatic? 

. * De ferred. Proprams , - will he loaded on separate tapes initially. 

I. The Use of I/O 


All object programs will he required to utilize the centralized I/O 

“ 8 sy8tem - be accoi,u”Sfny e ua^ 

calls to the Dispatcher indicating the particular i /0 service ^ 

®^ ired * ^ I /° Package will take care of any necessary code 
conversion or equipment formatting. ^ ^ tt 

^ior to asking for an 3/0 -transfer within an object program the 
program must first declare a File for the use of- that type of I/O 
activity. Then, when appropriate in the program, an i/C^call is 
J ?? 6 t 0 ^/n Di 8 ?f tCher «**«“*« «*• Eea' Stable) a!e 

f^ ble f ° r ^dltlonafl/O tuncSr^c^t for 
the first control word containing the object program name and rm m w 

any W orderf° 110Wine# ^ V ° rd elements of calls may be arranS in 
The following table lists the current formats for Dispatcher rai i a 

- 0814 f8I “ t8 (- ~ srxs' 


MnnBnnBni 
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3-7-63 8 dispatcher calls 

FORMAT OF CALLS TO THE DISPATCHER 


1.1 CALLING SEQUENCE CONVENTI 


ONS 


WHEN A PROGRAM MAKES A CALL TO THE DI SPATCHFR it utii ir 
TAB^e! ACCUMULAT0R THE LOCATION OF ITS PARAMETER REQUEST 

THE DISPATCHER WILL SAVE APPROPRIATE REG! STFR<; anh 
RESTORE THEM FOR SYSTEM PROGRAMS .STORE THEM FOR LATFR 
RESTORATION FOR NON-SYSTEM PROGRAMS. ATER 


1.2 

1 . 2*1 


CALLING PARAMETER TABLE FORMAT 

W0RD IN THE TABLE IE OF THE FOLLOWING FORMAT 
BYTE 0-3 NAME OF CALLING PROGRAM 1 TO 4 CHARACTERS I 

BYTE 7 NUMBER OF WORDS IN THIS TAB^eI jJJ? TlFIE0 
INCLUDING THIS WORD ' 


1,2,2 THE MA,N B00V 0F ™ E TARI - E Is w the 

BITS 0-35 PARAMETER NAME- 1 TO 6 CHARACTERS .LEFT ilKTiei 
BITS 36-41 VALUE TYPE- INTEGER WITH THE FOLLOWING VALUES 
: O-VALUE IS INTEGER 42 47 OF THIS WORD VALUES 

1-VALUE IS INTEGER IN NEXT WORD. RIGHT JUSTIFIED 

. 3-VALUE IS FLOATING POINT NUMBER IN NEXT WORD • . 

4*=THERE IS NO VALUE WITH THIS PARAMETER NAME 
5»VALUE IS 1 HOLLERITH CHARACTER BYTE 7 THIS WORD 
6-VALUE IS 2-8 HOLLERITH CHARACTERS LEFT JUSTIFIED 
IN NEXT WORE)* NUMBER OF CHARACTERS IS IN BYTE 7 
THIS WORD (A BINARY INTEGER). 6 

7 °Mcbr E M I , S «o!! AR8I I RARV ARRA NGEMENT OF INFORMATION I 
.^ E 2J N WORDS. N IS A BINARY INTEGER IN BYTE 7 OF T 
WORD 


1.3 


Jre“eded Q bv S I BE 0NLY 0NE ° e THE parameter 

Vilmnllml THE parameter .names in the call is not 

THE PARAMETER NAMES ARE ALL OPERATED ON AS 6 CHARACTFR 
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SIpa?cher I ^d L ^?ir F fJ^t S iJS E VARI0US reousts to the 

FILE - THIS IS USED TO RESERVE I/O EQUIPMENT FOR PROGRAM*; 

AND TO MINIMIZE TRANSMISSION OF INFORMATION ON MOVE 
ai A | LL ct, i T ALS0 MAY RESERVE A BLOCK OF SPACE ON DRUMS 
OF L A iR0GRAMS LA 0?ERA??0N" 0ULD ^ MADE AT THE BEGINf ^ 
DEFILE ” CAUSED S BY L FILE SERVATI0NS AND INF0RMATI0N STORAGE 

ASSIGN " A^nrI?T^ NIP ° LATE TAPE ’ BUT N0T F0R READING TAPE. 
Mm/r N - I5L! ILE NAME WITH LOGICAL I/O UNIT 


TAPMUV 

ASSIGN 

MOVE 


SCROLL - 

TOCORE - 
TODRUM - 

DELETE - 


A?CORD I NG F ?n M ?Mi?o ll S f EE ™ ANG f E ? RE ° T0 _ 0R ™OM CORE121 


ACCORDING TO INSTRUCTIONS iTfIlE DECLARATION C ° RE }|J 
^FORMATION WHICH HAS BEEN PUT ON DRUMS BY 

CAUSES FNTTIPq t E ENTFRED INTo INVENTORY 124 

CAUSES ENTTIES IN INVENTORY TO BE BROUGHT TO rnor « 

™ U ORUM INVENT ° R,Et> ENTITY ' N C0R ' TO°Be H IJ? E r E III 

*5sEl“RK A ™°? u If?!:fJ 0 „?E.25 M 2y?S FROM inventory}!. 


LO.O - CAUSES PROGRAM' ON .N^ATBD B^NArS TAPE T FR “ E INVEN ™' 
RELOCATED AND PUT ON DRUM BE 

T ' “o L pa«Ige N for 3 ma? RD " LL T ° 1/0 PACK4GE 1N 
««■" f ; f P ryF “ rU '0 oompleT£ U interrupt ETECT 

PARAMETER COMMENT VALUE 

NAME .. NUMBER TYPE SIZE va. up 


SIZE 


VALUE 


FILE 

UNIT 


NAME OF FILE 

0- CARDREADER 

1- PRINTER 

2- PUNCH 
1-TAPE 

4 - DRUM 

5- INPUT MEMORY 

6- 1/0 REGISTER 

7- CONSOLE TYPWRITER 

8- TELETYPE 


204 5 

205 3 

206 

207 

208 

209 

210 
211 
212 
213 


FORM 


b-binary 

h-hollerith 

C-709,0 CORE HOLLERITH 


214 

215, 

2151 


INLOC 


A) 1 


B) 6 


LOCATION OF FIRST CORE 216 3 

REGISTER TO TRANSFER-B I NARY2 162 
NAME OF PROGRAM OR TABLE 2165 1 
IN SYSTEM 1 







f 


^ 2 
3 


5 

7 1 

; 

1 

3 1 


f»| 1 
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A) 7 


B) 6 

C) 0 


TM-112' 

BITS 18-23 0=DRUM A 
1=DRUM B 
4=DAT0R DRL 

BITS 30-3 A = DRUM FIELD 
BITS 35-47 = DRUM ADDRES 
NAME IN INVENTORY 
0=RESERVE DRUM REGISTERS 
FILE NAME EQUAL TO NUMW 
RESERVE DRUM REGISTERS 
FILE NAME EQUAL TO INTF 
IN NFXT WORD 


3 1 


DENSTY (3) 


H=HIGH 

L«LOW 


NUMWDS ( 4 ) 


NUMBER OF WORDS TO BE MOV 


TAPE . ( 5 ) 


LOGICAL TAPE NUMBER 


COMMENTS 


(1) NOT USED IF UNIT EQUALS DRUM»INPUT MEMORY 

(2) USED ONLY WITH f>RUM 
t3) USED ONLY WITH TAPE 

(4) NOT NEEDED IF DRMLOC VALUE TYPE EQUALS 6 OR 0 OR IF 
NUMWDS PROVIDED IN MOVE REQUEST 

(5) OPTIONAL FOR USE WITH TAPE 

PARAMETER COMMENT VALUE ' 

NAME NUMBER TYPE SIZE VALUE 


4.2 * DEFILE 


NAME OF FILE TO BE EXPUN( 


4.3 * TAPMUV 


FILE NAME IDENTIFYING 
LOGICAL TAPE • 
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OPTION 


A=WR I TE END OF FI LE 
5=WR I TE END OF TAPE 
6 =REWIND 

7=BACKSPACE A RECORD 
8 =BACKSPACF A FILF 
9=SET HIGH DENSITY 
10=SET LOW DENSITY 
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A- 5 * ASSIGN 


FILF NAME 


TAPE 


A. 0 
B) 4 


LOGICAL TAPE NUMBER 245 3 

IF VALUE TYPE EO 4 DISPATCH-2452 i 
ER ASSIGNS TAPE AND LEAVES 2454 
LOGICAL TAPE NUM IN VALUE 2456 


PNAME 


PROGRAM NAME OF PROG USING 2458 3 
FILE IF NOT SAME AS CALLING 24585 
PROGRAM 24586 


TELETYPE NUMBER 


4.6 * MOVE 


IDENT (1) 


FILE NAME 247 
RELATIVE LOCATION IN SYSTEM248 
TABLES OF ENTITY TO BE 249 
MOVED 250 
IDENT CHARACTERS FOR TAPE 251 
TRANSFERS CAUSES THIS 252 
READ OR WRITE TO BE IN 253 
IDENT MODE 254 


NUMWDS ( 3 ) 


NUMBER OF WORDS TO BE MOVED 2542 3 


INPUT (2) 


CAUSES TRANSFER TO CORE 2553 



t 


m § 
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NUMBER TO BE ADDED TO IN 
OF FILE DECLARATION TO 
ESTABLISH MODIFED INLOC 
THIS TRANSFER ONLY 


DRUMIX (1) 


NUMBER TO BE ADDED TO DR- 
REGISTER AS DEFINED OR 
REQUESTED IN DRMLOC OF F 


DECLARATION 


TNSTAT 


THIS ITEM SET BY DISPATCH 
AT COMPLETION OF READ IF 
PROVIDED BY CALLING PROGR 

0- NORMAL 

1- END OF FILE 

2- END OF TAPE 


WDSIN 


DISPATCHER INSERTS NUMBE' 
WORDS READ FROM TAPE IF 
PROVIDED ' 


COMMENTS 

(1) OPTIONAL 

(2) EITHER INPUT OR OUTPUT BUT NOT BOTH- ARE USED 
( 3 ) NOT NEEDED IF GIVEN IN FILE DECLARATIONt 

IF USED OVERRIDES FILE 


.O: « 


4.7 # SCROLL 


NAME 


FILE NAME' IDENTIFIS AREA 
NOW ON DRUMS TO BE GIVEN 
INDEPENDENT IDENTITY “ 
NEW NAME OF ENTITY 


4.8 * TOCORE 


6 NAME OF PROGRAM OR TABLE 


I " 
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4.9 * TODRUM 

• 

j ; , 

6 6 

NAME OF PROGRAM OR TABLE 

270 5 

5.0 * DELETE ' 

1 • 

6 6 

NAME IN INVENTORY 

271 5 

i 

5*1 * LOAD 

f-]' '• 

Ik; • 

j . , * 

!' : ' • ■ 

1 J 

CHANNEL IN PQU OF PROGRAM 
TO BF LOADED 

271 5 

272 

273 


I , 


5*2 * DIRECT 


HI?. . 

jlii.. • 

Ml : 5.3 * CON 

II 1 1 1 ■ ' ' 


I'i ■ 


5.4 * IOCINT 


fin 


r/n T r! ° RDS co NTAIN 
I/O CALL IN FORMAT OF I /n 
PACKAGE. THERE WILL BE 

, CHECKS ON THIS 
REQUEST. USE ONLY AFTER 
CHECKING WITH SYSTFM 

designers. 


* s channel number 

CHECKFn^Pnb PR0GRAM T 0 BF 
CHECKED FOR CONFLICTS. 

£i S u£l£ HER INSERTs IN BYTE 
OF WORD CONTAINING CON 
0=NO CONFLICT 
1 “PGM ( S ) IN CONFLICT 
' BUT CAN NOW BE MOVED 
2*CONFLICT PROGRAM(S) 

NOW DOING I/O 
3*>CONFL ICT WITH PROGRAM ' 
IN PCUR 


2 75 
276 
2 77 

278 

279 

280 
281 


282 

283 

284 

7285 

286 

287 

288 

289 

290 

291 

2911 

2912 


V*f 

T 


THIS INDICATES AN 10 
COMPLETE INTERRUPT USED III 

ONLY BY SYSTEM E ° . \l\ 


9 9 
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© ' 


' Introduction 

Included in the description of functional capabilities of TSS Model 1 
(TM-H 26 /OOO/OO) • is on-line debugging. .This debugging capability refers to 
a set of permanently available routines in the Executive System that will 
perform the system user's requests for on-line debugging. An initial version 
of the debugging routines (hereafter referred to as program DBUG) axe now 
being checked out with TSS Model 1. The purpose of this paper is to provide 
a brief functional description and user's guide of program DBUG. ' 


S*A*4S0 10/U 


Although this document contains no classified information, it has not bean cleared for 
open publication by tha Department of Defense. Open publlcaUon, wholly or In part. Is 
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2.0 Debugging Commands - Language Conventions , 

The special character exclamation point (.' ) is used to identify TSS 
system command inputs. The special character quotes (" ) identifies an 
object program input. The first debugging command must be preceded by 
an exclamation point when changing from object program type of inputs t 
system command inputs. 

The following outlines the remaining general requirements of debugging 
inputs. - 
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2.1 Control Characters 

Each debugging command must terminate with onr or more of the thrc 
teletype characters: slash (/), number sign (#), and Bell (end- 
of-message key). • 

Slash (/) followed by Bell terminates a command to open a register 

Number sign (#) followed by Bell terminates a command to change a 
register. . . 

Bell (end-of -message key) terminates a command to specify a mask 
or format change. e 

♦ . y 

2.2 Blanks 

In general, blanks are ignored by DBUG. A blank (space bar on:.' 

. teletype keyboard) only serves as a field delimiter except when 
input as Hollerith value (enclosed in parentheses). Wherever 
one blank may occur, any number of blanks may occur. 

2.3 Numeric Inputs • 

Numbers used in debugging commands may be signed or unsigned octa 
decimal, or floating point; they may contain the following charac 

0123456789 . •£+-' 

Octal numbers are defined as being any string of digits 0 through 
7, terminated by an apostrophe (’). 
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Decimal numbers are defined as being any strin 
9t terminated by a blank or any other special 
etc.; except apostrophe (’) or period (.). 

Floating point numbers are defined as being an; 
a period (.) and/or terminating with an exponei 
the exponent is the power of ten by which the 1 
multiplied. The exponent starts with the lett< 
ately by the power of ten, which may be signed 
absolute value of the exponent must be less thf 
Example: 0.25E-6. 

2.4 Symbolic Name Inputs 

Any string of six or less alphanumeric characte 
letter and terminated by a blank or any special 
sidered a symbolic name. 

2.5 Hollerith Inputs 

Hollerith values may be used in debugging comma 
the value with parentheses. Prefacing the left 
count pf the number of characters and the type, 
machine Hollerith (non-sortable) indicated by 1 
core Hollerith (sortable) indicated by letter C 
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through 


•erating Instructions 


The following pages contain the detailed description of how the varic 
functions of the debugging routines are used. However, certain cond: 
tions must be met before requests to operate the debugging routines 
would be allowed. , 


lining 

jf 


immedi 

The 


a. An object program must have previously been loaded by the System 
Load Command. 


b. The execution of the object program must not have been terminate 
by the System Quit Command. . , v , 


!Vl ii' j 


i; - ■> 

■ ffl, j 


i: ; 
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3«1 Opening Registers 

In order to open a register and have the contents printed on the 
teletype, the address or a relative addresB followed by a slash 
must be input. Once the address of' a register is specified, it 
remains the open register address until a different one is specified. 
The following examples will illustrate opening a register. 

40000'/ (octal) 

1638V (decimal) 


I 1 -! lijViJ 


Teletyping either of the above commands will cause DRUG to print 
the contents of octal address 40000' on the teletype. DBUG will 
print the address and a sixteen character octal representation of 
the open register. 
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The above inputs will change the open register address by the 
amount shown (e.g., 40000’ becomes 40001’ in the first exampli 
and the contents will then be printed. 


The latter three examples all have the 
reopen the previously opened address. 


same effect, that is, to 



4 


27 June 1963 8 TM-II26/00V00 

3.3 Dumping 

< . ‘ 

bkbo ' 10/ 

This input will cause an octal dump to he printed. The first 
number is the starting address of the dump and the second is the 
number of registers to dump. After the dump, the last register 
printed (4451') will then be the open register address. The 
maximum number of registers allowed per dump is 20. 



x»Voo 
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3*4 Opening Machine Registers 


$A/ 

$B/ 

$l/ 

$p/ 

$xi/ 

$X2/ 

$X3/ 

$X4/ 

$X5/ 

$x6/ 

$X7/ 

$X8/ 

$LIV/ 

$d/- 


Accumulator 
B Register 
Logical Register 
Program Register 
Index Register 1 
Index Register 2 
Index Register 3 
Index Register h . 

Index Register 5 
Index Register 6 
Index Register 7 
Index Register 8 > 

Live Register 

Double Index Selection Register 


Any of -the above inputs will cause the contents of the corres- • 
ponding machine registers to be printed. The settings of these 
registers will be as they were when the execution of the object 
program was last interrupted. The environment at that time is 
saved, along with other information used by the system in a block 
of registers at the end of the object program. These environment 
registers, therefore, are the ones that are displayed in the 
•examples shown above. 

Also, the address in the environment block of the machine registe: 
referenced then becomes the open register address. 






3*5 Displaying' the Panel 
$ PANEL/ 

This debugging command will cause all the machine environment 
registers referred to in section 3.4 to be printed. Currently this 
is done by printing 14 lines of output, one register per line. 
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3*6 Changing Register Contents 


^ °^ 6r ^ t0 ? har f? the c °ntents of any register in the object 
pr gram (instructions, data, or environment area), it is first 

S! C S! ar3r 1° ° P f n register. The value to be inserted foil 
by the number sign (#) can then be input. DBUG will indicate \ 
e change is effected by typing the response $IN. The value i 
serted will replace the entire contents of the open register ur 
a mask was previously specified indicating thay only part of tl 
b f changed ; Specifying masks is described in section 
Th following example shows the method of changing a register: 


40001 '/ 
C(040001‘) 


Debugging Command 
Debugging Response 
Debugging Command 
Debugging Response 


This sequence of commands to and responses from DBUG would fire 
open register 40001 ' and then set it equal to zero. 

v f 1 } ie ma y be 611 octal number, a decimal number, or a 
floating point number. The number is always right lustified 
th. active bits of the open resisted (m biS 
active unless otherwise .specified by a mask. ) 

Si Se a iiSeSi. S< ’ ,Ue “' :< ' ° f hiS Pr ° P rm bJr cha "»”8 ’ 




3*7 Setting Masks 
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When only certain hits of the open registers need to he changed, 
it will sometimes he easier to specify a mask that will apply to 
the changes that will he sbusequently input. This is done by 
specifying the starting hit position of the mask and the number of 
hits in the mask. DBUG will respond by printing the octal repre- 
sentation of the mask. Once a mask is specified it remains in 
effect for all change inputs until a new mask is specified. The 
following examples show how masking a change can be done. 


hOOOk'/ 

c ( okoook ') = 2000037616000020' 
18 6 

MASK - 0000007700000000 
60'# ' ; ' . • . 
|IN • ; 


Debugging Command 
Debugging Response 
Debugging Command 
Debugging Response/ 
Debugging Command 
Debugging Response 
Debugging Command 


C(040004') - 2000036016000020' Debugging Response 
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A variety of errors can occur while inputting debugging requests. Wh 
an error is encountered, DBUG prints an error number and the request 
ignored. The following is a list of the error numbers and what they 
mean. 


ERR 1 Inactive teletype 

ERR 3 Program not in core 

ERR 6 Load in progress, a system error 

ERR 7 Illegal input, should be easily recognized error in the 



context of the preceding debugging request 
ERR 8 Octal number containing an 8 or 9 digit 

ERR 9 Numeric input too big, l4 digit decimal, 16 digit octal 

ERR 10 System error, this input may be later recognizable when a 

' . new function is added 

ERR 11 Too much input, more than 32 characters in input message 

ERR 12 -Floating point number format error 

ERR 13 Symbolic name greater than 6 characters 

ERR 14 Opened address greater than 177777' 

ERR 15 Attempt to change a register outside of object program re 

ERR 16 Illegal request for a panel register 

ERR 17 No such index register 

ERR 18 Opened address is zero or minus ‘ . ■ 

ERR 19 Insertion format error 

ERR 20 Too large a dump request, maximum of 20 

ERR 21 Illegal symbolic name . 

ERR 23 Should be only one exclamation point 

ERR 24 Illegeil control character, should be / or # 

ERR 25 Illegal mask, too big or too small 
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addendum to TIME-SHARING SYSTEM (TSS-1) 
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Interim Operational Design and User 8 s Guide for Model 1 
Time-Sharing System (TSS Model 1), presented a nnni r T P h fl n C t- f0 — r-ier of th 
^rSr^stem , 'bein'i i pFeloped July, 1963. During the course ofsys tern 
implementation several operational design changes have been made, as veil as 
certain system conventions. Furthermore, certain concepts in the original 
document were not adequately explained. This addendum describes presfnt 
operational changes in the time-sharing system and clarifies certain time- 
sharing system concepts and programming techniques. 

1- Quantum Interrupt 

d i SC ^ SSl ° n ° f time - faring, reference was made to the on- 
sm£ll Sic! S Programs on a quantum basis. The quantum is a 

11 f during which a* 1 object program can operate. An 

object program will run for one quantum and if it is not finished (i.e. 
it has not returned control to the Executive system at its logical con-’ 
elusion or because of i/o transfer requests), an external timer vill 
generate an interrupt, the quantum interrupt. The object program vill 

timf r °T t n v^T S ?° int Untfl itS turn t0 °P erate occurs again; at that 
time, it vill be given operating time again. 

The scheduling algorithm does not alvays limit object program operation 

r JU !^^ e / Uan ! Um Sa ? h time " A Category 1 program (programs less than 
16K, vhich do not use lov-speed l/o (tapes) vill begin vith one quantum, 
and if not finished, vill double the quantum length each successive time 

of S 8 Sli^° Pe n a ! e ° CC T (i ° 6 ^ 4 quanta, etc., to a maximum 

01 0 quanta). Category 2 programs (programs vhich use lov-speed l/o and 

range in size from 16 k to 32K) vill start out with 2 quanta of operating 
time and double each successive turn to a maximum of 8 quanta. Category 
3 programs (programs over 32K) vill alvays operate on an 8 quanta basis! 
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'! 

Production runs (RUN) will not operate on a quantum basis, but will run 
until complete or interrupted by a higher-level program (Category 1, 2, 
or 3). 

2. Executive and Object Program Message Switch 

The Exclamation Mark (') used to identify an Executive command will not 
have to be repeated for consecutive Executive commands., That is, if 
several Executive commands follow each other directly; only the first 
one must be preceded by the Exclamation Mark. To send inputs to an 
object program^ an initial Quotes symbol (") must be given, at the start 
of a new^message, and all further input will be passed on to the object 
program o To revert back to the Executive mode, the Exclamation Mark (•) 

is entered again. This procedure provides a simple two-way switch 
whereby the user may rapidly change between the Executive and object 
program mode of input. 

3° "Pure" Programs 

Some confusion resulted from the reference to "pure" programs. A "pure" 
program is considered to he one that does not modify itself and contains 
ail object data (user context) in tables. This approach would permit a 
program to service several users in parallel; that is, while processing 
one user, it can be interrupted, service another user, interrupt, continue - 

processing the first user, etc. The "pure” program separates context from 
the computational processes. There is no need for object programs to be 
concerned about being "pure"; such a technique is primarily applicable to 
general system service functions. 

4. Using JOVIAL J-2 For TSS-1 

The currently available J=2 JOVIAL can be presently used to program for 
TSS-1. The only change required is that all i/o references utilize the 
Dispatcher i/o call format. In addition, the program should not come 
to a halt (STOP); this instruction should be replaced with a 

BUC 303 ' 

Col. 8=10 Cols. 24=27 - An item may he equated to this 

absolute address. 


The J-2 symbolic deck should he compiled without a COMPILE card. (Begin 
with START to eliminate the dictionary. ) The binary deck must then be 
loaded on to tape with a special tape-loading program of the time-sharing 
system. In JTS, a GOTO SYSTEM $ will do the same as above. No J-2 
library procedures are valid for time-sharing except LOC. 


After GO and RESUME, the (") mode is automatically entered by the system. 


1 . ; 
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Dispatcher i/o Calls 

The calling sequence for l/o in TSS-l has been designed to be very 
flexibie in terms of format and expandability for new i/o functions. 
{See Appendix A. ) Several useful hints can be given as to their use 
object programs. 

A. The I/O Call Format 

The I/O calls are basically Hollerith tables with some non-Holier 

r? tr i eS ° 1116 order of the parameter entries is not fixed except 

the first control word and certain two = word combinations. The fi 
control word must always contain the following; 


Bytes 0=3 


Byte 6 


! Name of object program (up to 4 characters, lef 

justified) 

Sortable, Non=sortable Hollerith Indicator for 
Dispatcher call itself only . — ~ * 

1 = Sortable 0 = Non=sortable 

(For J~2, Hollerith is sortable; SCAMP uses non-sortable 
Hollerith) 

Number of entries in this call excluding this 
control word (integer). 



Byte 7 

Example: 

Byte 


The program name is PIPl, the call is in Hollerith, and this call 
will have 5 parameter words following the control word. 

(Blank bytes should be Hollerith blacks, not zeros . ) 

• 

Only one i/o function may be requested in a call at a time. The 
parameters for this call are specified by the desired function. 
The value type number (byte 6) specified by the i/o function forms 
must always be included. (Sec. 1.2.2). If an additional number - 
byte 7 is required, it will be specified by the value type number 
byte b. If this means that a succeeding word contains related 
information, the current word will so indicate by means of the vaJ 
type. 

Example: 
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The l/o function is FILE (declaring an input and/or output file for 
a particular type of l/o equipment), the name of the file is located 
in the next word ( 2-8 characters, left justified), and the file name 
is s_lx characters long- These two words must be consecutive. File 
names must be 6 characters, including trailing spaces. 



Byte 
I0CALL 
Entry 0 


1 

2 

3 

4 

5 

6 ( 1 ) 

7 

8 ( 2 ) 


p 

I 

P 

1 



1 

1 

8 

F 

I 

L 

E 



6 

6 ) 

M 

E 

S 

A 

G 

E 


' 

U 

N 

I 

T 



0 

8 

F 

fi 

R 

M 



5 

C 

I 

N 

L 

0 

C 


1 

l 






14 

44 


N 

U 

M 

W 

D 

S 

1 

”1 







> 

20 8 ) 


* 


Entry 4, F0RM, indicates that the data to be transferred will be in 
sortable (core 7090) Hollerith form. The call itself does not have 
to be in the same type of Hollerith as the data it refers toTn the 
file<> Entries 6 and 8 will be non°Hollerith entries 0 Entry 6 (l) 
can be set (in J=2) by using the L0C procedure to get the address of 
the table for use by the I/O file. (Example: IjZSCALL($64j = L0C 
(TABLEl)$). In JTS, it will not be necessary to use LJZ$C, since the 
table address can be gotten directly. 

(Example: l/CALL($ 6 $) = TABLE! $) 

Entry 8 (2) will require an integer setting. 

(Example: I^CALL ($ 8 $) = l 6 $ (20 g ). 

Entr y 5.» the IM^C parameter. Is optional for any of the FILE cedis. 
If it is not specified the INL$C will be set to zero. Whether or not 




* 


Entries must be paired together in order 0 
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INl/c is used, however, you may employ the C0REIX parameter in the 
MOVE call to specify the absolute location of the data. 

It should he noted that several FILE calls (names) can he used for 
one data area in a program- Also several data areas can vise one 
FILE call hy means of the C0KEIX (MOVE) procedure described above. 
That is, location references can be changed each time the MOVE is 
given. 

The NUMWDS entry ( 7 , 8) is optional, since the number of words to b 
transferred can be specified in the specific transfer reqest (MOVE) 

A call to transfer teletype input into the object program: 

Byte .01 2 3 4 5 6 7 

Entry 0 


1 


2 


3 


4 


5 


The NUMWDS parameter must be declared either in the FILE call or ir 
the MOVE. However, the NUMWDS parameter is not functional for tele 
type input, since the number of words actually input from TTY (up t 
20) will be transferred to the program. Therefore, it is important 
to make the table area for such inputs at least the size of a 
maximum TTY input (i.e., currently 20). 

A call to transfer teletype output from the object program: 

Byte 0 1 2 3 4 5 6 7 

Entry 0 


1 

2 


3 


4 


5 



p 

I 

P 

1 



1 

5 

M 


V 

E 



6 

6 

M 

E 

s 

A 

G 

E 



I 

N 

p 

U 

T 


4 


N 

U 

M 

W 

D 

S 

1 
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The same file name refering to one program table, has been used for 
both input and output of teletype messages „ This practice is not 
recommended, however, and separate tables should be used for input 
and output. This is because ix will be possible to generate outputs 
while in the process of scanning input, and the two functions should 
not interfere. 


The NUMWDS parameter (entries 4, 5) is optional; it is not needed if 
specified in the FILE call. (The MOVE: call, NUMWDS, will, however, 
override the FILE entry of same.) 

A FILE call for drum spaces'" 



Entry 3, the 32JL0C parameter, is optional for any of the FILE calls. 

If it is not specified, the INL0C will be set to zero. Whether or not 
INL0C is used, however, you may employ the C0REIX parameter in the 
MOVE call to specify the absolute location of the data. 


For the initial TSS system, an object program may ash for the use of 
' up to 8k of drum space for its own operational use. This drum space 
will only be available on the Bator drum (unit 04) . Entry h is set 
by using LOC (Table) in J=2. 


The i/o calls to transfer to and from drum, is similar to those shown 
for teletype, except that an additional parameter may be added to 
modify the drum or core location (INL0C). (The core location (i.e., 
TTY input or output table) may also be modified for teletype I/O 


Drum space for object programs is currently unavailable; l/o calls for drum 
by an object program will be recognized. 


t 
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A FILE call for tape; 


Byte 
Entry 0 


1 

2 

3 

k 

5 

6 

7 

8 


0 

1 

2 

3 

k 

5 

6 

7 

p 

I 

P 

1 



1 

8 

F 

I 

L 

E 



6 

6 

l 

1 







I 

N 

L 

0 

C 


1 


:j to233g 

u 

N 

I 

T 



0 

3 

F 

0 

R 

M 



5 

c 

N 

u • 

M 

W 

D 

S 

1 


!20 8 


k *FILE nan 
. correspc 
LOAD con 
file rel 

, * 


The calls for transfers are the same as shown for teletypes. 

The INL0C parameter is optional for any of the FILE calls. If it is 
not specified, the INL0C will be set to zero. Whether or not INL0C 
is used, however, you may employ the C0REIX parameter in the MOVE 
c an to specify the absolute location of the data. 

It should be noted that only one record at a time can be transferred 
using a MOVE call for tape. For each record desired to be transferr 
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in or out, a MOVE call must be given. The number of words in the 
record are specified by the NUMWDS parameter. 

The INSTAT is to be used with the MOVE or TAPMUV declaration. WDSIN 
is used only with the MOVE declaration. Neither is used with the FILE 
declaration. 

The FILE call for tape should include an entry of FORM (Entry 6). 

This specifies the word format on tape to be in binary or Hollerith. 

If FORM is not included in the FILE call, the Dispatcher will assume 
that binary is desired. 

Additional Parameters for Tape FILE Call 

Two additional parameters may be used in a tape FILE call by an 
object program. These will permit an object program to ask for a 
specific tape reel number to be mounted on a tape drive, and have 
the tape file protected. 


Tape Reel Number 


Byte 

0 

1 

2 

■ 3 

h 

5 

6 

7 

Entry A 

R 

E 

E 

L 



6 

4 

B 

1 

2 

3 

h 






, i If the REEL parameters are omitted (both entries A and B), a blank 

tape will be assumed for mounting. Also, if the reel number entry 
| T (B) is all zeros (this whole word must be zeros not blanks), the 

operator will mount a blank tape. The user will then receive a 
printout on his teletype as follows: 

$FILE AAAA DRIVE XX REEL XXXX (The reel number, if 

a blank tape, will be 
inserted by the 

J operator . ) 

i ' |i 

: : ( ! This provides the user with information about what tape reel has been 

; ; f given to him and its drive location. In the event that the system 

halts during object program operation and is restarted, the user 
should determine whether or not the "mount" tape (used by the object 
program) should be rewound or not. This will depend on how his 
program operates and the validity of partial tape output. If the 
tape is to be rewound whenever the program starts, a TAPMUV call 
should be given by the object program. If rewinding is optional, the 
j object program should query the user whether to rewind, write end- of - 

file, etc. It will also be possible for the user to notify the 


* Entries A and B must appear together in sequenced 
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operator at the time of program restart to rewind the tape, if 
necessary. 

File Protect 


If the tape reel to be mounted should be file protected, the 
following optional entry should be included in the tape FILE call: 


Byte 


If this entry is omitted, or byte 7 is a zero (instead of a one), 
or the FILE call specifies a blank tape, then the tape will not 
be file protected,. 



A call to write end-of-file on tape: 



This call can be used with various options to backspace, rewind, 
set density, write end-of-tape, etc. 

Drum and tape files should be "defiled" if no longer necessary by 
the program. 


Example : 
,Byte 


0 

1 

2 

3 

k 

5 

6 

7 

p 

I 

P 

1 



1 

2 

D 

E 

F 

I 

L 

E 

6 

6 

t 

1 
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Note; An object program can be written to use tapes (and drums) 
optionally. That is, the FILE and MOVE calls do not have to be 
operated in the program code. However, if tapes will be used by 
the program for a particular run, it will be necessary to specify 
tape requirements in the LOAD (Executive) command or else the 
object program will be terminated by the Dispatcher. 

B. I/O Call Tables 


It is convenient to establish one or more tables to contain the i/o 
call information. To avoid confusion and minimize housekeeping, 
certain types of frequently used calls can have separate tables. 

For example, the MOVE calls, shown in the previous examples, would 
only require two entry changes for changing from input to output 
and vice versa. However, changing from FILE to MOVE is a complete 
change. It appears, then, that i/o calls that are used often and 
which vary radically in format can be conveniently handled by 
separate tables. 


<), 


TABLE CALL R 10 1 $ 

BEGIN 

ITEM CALLH 8 0 0 N S 
ITEM CALLI 48 S 00 N $ 

END 

C. Calling the Dispatcher 

When an object program has set up its i/o call parameter ' table, it 
can then go to the Dispatcher for service. To do this, it is 
necessary to go into direct code (for J~2) as follows: 

DIRECT $ 

ASSIGN A = PLACE $ 

BUC 312 5 

Cols. 8-10 Cols. 24-27 " An item may be equated to this 

JOVIAL absolute address. 


Normally, FILE will not be called for except initially in the program; 
however, MOVE will be used very often for teletypes as well as tape 
and drum transfers. The teletype MOVES may well be separated from 
the other i/o MOVES. 

Since 1 the Dispatcher calls involve both Hollerith and integer 
parameters, the i/o call table should be declared as having two 
kinds of items as follows: (j-2) 


I) 
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PLACE is an arbitrary integer item which has been set previously to 
the address of the I/O call parameter table. (PLACE = L0C (CALL)$). 
Operation of the object program will be returned to the next instruc- 
tion following the BUC to the Dispatcher address when the i/o request 
has been satisfied. 

D. i/o Call Errors 

Any mistakes in the i/o call format, or if the i/o call location give 
to the Dispatcher is in error, will be reported on the user's telety] 
(and on a dump tape)^ and the object program will be terminated. 

E. Tape Maintenance 

Additions to the Dispatcher calls are being planned whereby, the 
object program can specify appropriate action in cases of tape parit; 
end-of-file, end-of-tape, etc. This will involve tape demounting, 
labeling, and remounting functions by the computer operators. 

6. Multiple Teletype Channel Assignment For One Object Program 

Object programs, which axe written to service several teletype stations 
simultaneously, can inform the system via Dispatcher calls which teletyp 
stations are to be joined to the initial program channel (program origi- 
nator). The following Dispatcher call is to be used for "joining" a 
teletype station to the originator's programs 


Byte 

0 

1 

2 

3 

4 

? 

6 

7 

Entry 0 

P 

I 

P 

1 



0 

1 

1 

J 

0 

I 

N 



0 

XXq 


- TTY stat 
number 


Entry 0 is the standard Dispatcher control word containing the program 
name (up to four characters), in byte 6 is an indication of the Hollerit 
code used in the call (l = Sortable, 0 = Non-sortable, and byte 7 indica 
one word in the remainder of the call). 

Entry 1 contains the parameter JOIN, a zero in byte 6 (indicating that 
byte 7 contains the value for JOIN^ and an octal number specifying the 
desired teletype station to be joined. The JOIN call should be re- 
peated for each station desired, and the originating teletype station 
number should also be joined, in order for the object program to know 
its channel address. 
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Teletype stations which are joined, can all communicate with the origi- 
nating object program. However, the program must he properly prepared to 
handle input and output for several stations . Joined channels will be 
initially operating in a GO status; however, normal system commands, e.g., 
STOP, QUIT, etc. will be honored for that individual station. Once a 
joined station has QUIT independently, it cannot be rejoined except by 
repeating the JOIN procedure again from the originating station. DBUG 
operations can only be performed by the originating station, not the 
joined stations. 

Object programs which will handle joined stations should be prepared to 
query the originating station (via teletype) as to which station numbers 
(including its own) should be joined. This is an initializing procedure 
which can be dealt with conveniently using the teletype. Provision may 
also be made to re-join a station which has QUIT, by creating a sepcial 
command input to the object program. 

Note; This call is not for use with object programs which are designed 
for only one TTY station (user). 

7" Rescue 

A Dispatcher call will be available for a special non-l/ 0 use, which 
will permit an object program system to take responsibility for certain 
types of FIX errors. That Is, under certain FIX error interrupt conditions, 
the information will be relayed to the object program and control 
branched to a designated error entry location in the object program. 


Byte 0123^^67 


Entry 0 

P 

I 

p 

m 

SI 


0 

1 

2 

1 

R 

Q 

s 

c 

u 

E 

n 

■ 

2 
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Entry 0 is the standard control word for Dispatcher . calls containing a 
program name (up to four characters), byte six indicates whether the 
Hollerith characters in the call itself are sortable (l) or non-sortable 
(0), byte seven indicates that two more words are in the call. Entry 1 
must be set as indicated. 

Entry 2 will contain the absolute location of an error routine in the 
object program, where the system will branch to after a FIX error 
Interrupt. 
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When the Dispatcher receives the RESCUE call at the start of object 
program operation, it will set a status item indicating that this prog 
will take responsibility for handling FIX errors caused by the object 
program. At the time an error occurs, the system will do the followin 

a. Set the object program panel environment storage to the values 
existing at time of interrupt. (These include the Accumulator, B 
Reg, Live Reg, Index Regs, etc.) 

b. The same interrupt (error) environment will be reestablished in th 
machine registers. 

c. The system will branch to the error routine location in the object 
program specified in the RESCUE call. 

d. The system will insert a value, indicating the type of error, into 
the register following the error entry location specified in the 
RESCUE call. The error value will appear in byte 7 and have the 
following meanings : 

1 = Illegal branch into FIX. (This error will not permit saving t. 

interrupt panel environment, and the panel will reflect the 
environment of the object program at the time it last went to 
the system. ) 

2 = Illegal instruction. 

3 = Illegal address reference. 

4 = Illegal division. 

5 = Program halt. 

In all cases, the error address may be off by one register (-tl). 

e. In addition to the above, the system will print out an error messa; 
on the user's teletype. 

Note: Object programs which use RESCUE must be prepared to handle 
these error conditions in one way ox another. For 'example, in IFL 
‘it may go into a trace dump, or if the error is too serious to 
continue operation, the object program should notify the user to 
quit. , * 











; 
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8. Teletype Control Characters 

Teletype code will be converted by the system to and from Hollerith for 
object programs. In addition to the normal. printable characters in the 
code set, certain control characters for teletype will also be available. 
These are not standard Hollerith characters and are set to specific octal 
values. 

End-of-message JJq 

Line Feed & Carriage Return 32g 

Input messages should terminate with a byte containing 77 fl ; this will 
cause the TTY output routine to stop character transfer after that point. 
Three limits on TTY output exist, as far as the number of characters 
actually transferred is concerned. The first type of cut-off point is 
the end-of-message character 77g> as described above. The second type 
of cut-off is the number of words specified in the i/o call (NUMWDS). 
Finally, the maximum limit of the output drum buffer is twenty words or 
ninety- six characters. This limit includes control characters which must 
be added in the teletype conversion and no more than eighty characters 
should normally be sent at one time. If the character limit is exceeded, 
the excess will be lost (not transferred). This output limit of 9 6 
characters will be changed when the peripheral computer is installed 
(PDP-1). 

The system teletype output routine currently prefixes all output messages 
with a line feed and carriage return. This means that object programs 
do not have to provide this control character intheir messages, except 
for formatting within an individual output message. The system will 
automatically line space individual messages and the object program may 
line space within individual messages using the line f eed/carri age return 
character (32g). 

If messages from the object program are generally long, print them out in 
short bursts to avoid losing characters. When in doubt, print it out.’ 

9° Program Checkout 

Object programs written in J-2 can be partially checked-out by using 
the Q=32 JOVIAL Support System. This will permit satisfactory parameter 
testing to be accomplished. A convenient method of testing the object 
program is to replace all exits to the Time-Sharing System 
(Executive or Dispatcher) by the procedure call for the JOVIAL system 
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symbolic table and item dump and use simulated inputs. This will re- 
the cirtical input and output functions for debugging purposes. Aftf 
this type of testing is complete, the program may then be cycled by 4 
Time-Sharing System for final checkout. 

10. JTS (JOVIAL for Time-Sharing System) 

There will be several changes in the Executive command (teletype opej 
for calling the JTS compiler. These changes will be described in th« 
documentation of JTS when it becomes available for use. This should 
affect object program preparation. 

11" Object Program Core Location 

The initial phase' of the Time-Sharing system will not provide space- 
sharing of core memory by object programs until memory protection is 
available. Object programs will be given absolute core address assif 
ments by the programmer prior to (for SCAMP) or at binary tape loadii 
time ( J-2 and other relative-addressing compilers). The legal limits 
for ORGing an object program run from 40000 ft to 172000 ft . The core sj 
declared by a program (within the above limits) must include all tab - : 
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8 DISPATCHER CALLS 


FORMAT OF CALLS TO THE DISPATCHER 


2 0 


CALLING SEQUENCE CONVENTIONS 

^° GRAM MAKES A CA LL TO THE DISPATCHER IT WILL LEAVE 
IN THE ACCUMULATOR 1 HE LOCATION OF ITS PARAMETER REQUEST 
'ABLE • 

DP ™L D * SPATCHER WILL SAVE APPROPRIATE REGISTERS AND 
R ° RE THEM F0R SYSTEM PROGRAMS, STORE THEM FOR LATER 
RESTORATION FOR NON-SYSTEM PROGRAMS. 


1.2 CALLING PARAMETER TABLE FORMAT 


1.2.1 THE FIRST WORD IN THE TABLE IS OF THE FOLLOWING FORMAT. 


BYTE 0-3 NAME OF CALLING PROGRAM M TO 4 CHARACTERS, 

rytp p -r^or- LEFT JUSTIFIED 

nylr % mmmdcd HOLLERITH 1 = SOR TABLE 0 = NON SORTABLE 

byte 7 NUMBER OF WORDS IN THIS TABLE, NOT 

INCLUDING THIS WORD 


12 1 
13 

1311 
1 A 1 
15 


1,2,2 THE MA,N B0DV 0F THE rlBLE 15 0F THE 55 2 

bits 0-35 PARAMETER NAME- 1 TO 6 CHARACTERS , LEFT JUSTIFIED 19 1 

BITS IK 1 ! 1 VALUE TYPE “ INTEGER WITH THE FOLLOWING VALUES 20 1 

0 = VAL UE IS INTEGER 42-47 OF THIS WORD 21 

RVALUE IS INTEGER IN. NEXT WORD, RIGHT JUSTIFIED 22 

3=VALUE IS FLOATING POINT NUMBER IN NEXT WORD 
4=THERE IS NO VALUE WITH THIS PARAMETER NAME 24 

5-VALUt IS 1 HOLLERITH CHARACTER BYTE 7 THIS WORD 25 

S^VALUE IS 2-8 HOLLERITH CHARACTERS LEFT JUST I F I ED 26 

IN NEXT WORD. NUMBER OF CHARACTERS IS IN BYTE 7 77 

THIS WORD (A BINARY INTEGER). 28 

7=VALUE IS AN ARBITRARY ARRANGEMENT OF INFORMATION IN 29 

NEXT N WORDS. N IS A BINARY INTEGER IN BYTE 7 OF THIS 30 
WORD _ 

31 


Jre?eeDED°by 5 A ™BELo" N BE ° NL '' 0NE ° F ™ E P#RAMETER NAMES 32 2 

SIGNIFICANT*" ™ E P#RAMETER NAMES IN THE CALL IS NOT 34 i 

3 5 


IS NOT 
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2 0 


l'?EMst R f?F^^t,^'!c?rS RE o LL 0PERATED ON AS 6 CHARACTER 
Ear S ; N L U N F ;sE^ARA?TERl LANK CHAR#CTERS > N ° P EER ° EE MUST 

WHEN A PROGRAM IS REENTERED IT WILL BE AT THF inrirrnM 
IN THE PROGRAM REGISTER UPON ENTERING THE DISPATCHER 


4 2 

5 


THE FOLLOWING LIST DEFINES THE VARIOUS REQUSTS TO THE 
DISPATCHER AND THEIR FUNCTION 


2.1 FILE 


.0 

3 



2.2 

DEFILE 

u 

2 


.2 

1 2.3 

TAPMUV 

13 



’.311 

m 

% 


.4 

1 2.5 

ASSIGN 

i5 




2.6 

MOVE 

.6 

2 


17 

2.7 

SCROLL 

.9 

1 



2.8 

TOCORE 

20 

1 


’1 

.2.9 

TODRUM 

.'2 



23 



24 

3.0 

DELETE 




! 6 

3.1 

LOAD - 

7 



28 



79 

3.2 

DIRECT 

0 



Jl 




32 2 
3 3 

4 1 

5 


THIS IS USED TO RESERVE I/O EQUIPMENT FOR PROORAMF 
AND TO MINIMIZE TRANSMISSION OF INFORMATION ON MOVE i 
J. T _^ LS0 MAY RESERVE A BLOCK OF SPACE ON DRUMS, i 

OF A JroGRAMS A oJer2??on"° ULD ^ ^ AT ™ E BEGI ™ING J 


CAUSED BY FILE l INC UKMA T I ON STORAGE ] 

J 

2.3 TAPMUV - USED TO MANIPULATE TAPE, BUT NOT FOR READING TAPE. 1 

2.5 ASSIGN - ASSOCIATES FILE NAME WITH LOGICAL I/O UNIT 1 

2.6 MOVE - CAUSES INFORMATION TO BE TRANSFERRED TO OR FROM CORF- 

ACCORDING TO INSTRUCTIONS IN FILE DECLARATION 1 

2.7 SCROLL - CAUSES INFORMATION WHICH HAS BEEN PUT ON DRUMS BY 1 

OBJECT PROGRAM TO BE ENTERED INTO INVENTORY } 

2.8 TOCORE - CAUSES ENTTIES IN INVENTORY TO BE BROUGHT TO CORE 1 

2.9 TODRUM - CAUSES INVENTORIED ENTITY IN CORE TO BE PLACED 1 

ON DRUM 1 

1 

3.0 DELETE - CAUSES PROGRAM OR TABLE TO BE REMOVED FROM INVENTORY! 

3.1 LOAD - CAUSES PROGRAM ON INDICATED BINARY TAPE TO BF i 

RELOCATED AND PUT ON DRUM J 

3.2 DIRECT - CALL CONTAINS 3 WORD CALL TO I/O PACKAGE IN , 

I/O PACKAGE FORMAT j 

3.3 CON - CALL FOR USE OF SCHEDULER TO DETECT CORE CONFLICTS 1 

3.4 IOCINT - ENTRY FOR 10 COMPLETE INTERRUPT 


JOIN 


' AN R OWECrpRTORA^. TTY STA " 0N T ° C ° MMUN,CATI E WITH 1 
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3.6 RESCUE 


ENABLES AN OBJECT PROGRAM TO RETAIN CONTROL AFTER 
A FIX INTERFACE ERROR INTERRUPT . 


PARAMETER COMMENT 
NAME NUMBER 


VALUE 

TYPE SIZE 


VALUE 


4.1 * FILE 


NAME OF FILE 


204 5 


UNIT 


0=CARDREADER 

IMPRINTER 

2=PUNCH 

3=TAPE 

4=DRUM 

5=1 NPUT MEMORY 
6=1/0 REGISTER 
7=C0NS0LE TYPWR ITER 
8=TELETYPE 

9=REM0TE HIGH SPEED DEVICE 


205 

206 

207 

208 

209 

210 
211 
212 
213 
2132 


FORM 


B = B I NARY 
H=H0LLER I TH 

(NON-SORTABLE) 

C = 7 090 CORE HOLLERITH 
(SORTABLE) 


2151 


INLOC 


A ) 1 


B ) 6 


LOCATION OF FIRST CORE 216 3 

REGISTER TO TRANSFER-BINARY 2162 
NAME OF PROGRAM OR TABLE 2165 1 

IN SYSTEM 2167 


DRMLOC 


A) 7 


B ) 6 
C ) 0 


BITS 

18-23 

0=DRUM A 

218 



1 =DRUM B 

219 



4=DAT0R DRUM 

2192 

BITS 

30-34 = 

DRUM FIELD 

2194 

BITS 

35-47 = 

DRUM ADDRESS 

2196 

NAME 

IN INVENTORY 

2197 


0=RESERVE DRUM REGISTERS IN 221 
FILE NAME EQUAL TO NUMWDS 222 
RESERVE DRUM REGISTERS IN 223 
FILE NAME EQUAL TO I NTEGER224 
IN NEXT WORD 



i\) im w (y 
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137 m $ 

138 


DENSTY (3) 


5 


H=HIGH 
L = LOW 


201 0 
202 


NUMWDS ( 4 ) 


NUMBER OF WORDS TO BE MOVED 


204 5 


2 05 3 

206 

207 

208 

209 

210 ' 
211 
212 
213 



214 3 

215 

2151 


16 3 
162 
165 1 
167 


TAPE (5) 

REEL ( 6 ) 

PROTEK (7) 


logical tape number 

TAPE REEL NUMBER (OR DECK) 

0= FILE PROTECT TAPE 
1 = DO NOT FILE PROTECT 


COMMENTS 

!i! used u o "y , E,s; , Sr5S uals orum>input 

(3) USED ONLY WITH TAPE 

(4) NOT NEEDED IF DRMLOC VALUE TYPE EQUALS 
NUMWDS PROVIDED IN MOVE REQUEST 

(5) OPTIONAL FOR USE WITH TAPE 

m omXt Ton til i,?S ^ S READER > 


6 OR 0 OR IF 


218 3 

219 
2192 
2194 

2196 

2197 1 
■ 221 1 
3 222 

•N 223 1 

• ;224 
225 


PARAMETER 

NAME 

COMMENT 

NUMBER 

VALUE 

TYPE SIZE 

VALUE 

4.2 * DEFILE 


6 6 

NAME OF FILE TO BE EXPUNGED 



4.3 * TAPMUV 


6 


6 


FILE NAME IDENTIFYING 
LOGICAL TAPE 
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OPTION 


0 


4=WRITE END OF FILE 
SPRITE END OF TAPE 
6=REWIND 

7 = BACK.SPACE A RECORD 
8=BACKSPACE A FILE 
9=SET HIGH DENSITY 
10=SET LOW DENSITY 
DENSITY CAN BE CHANGED ONLY 
ON TAPES IN REWIND POSITION 


237 

238 

239 

240 

241 

242 

243 
2432 
2434 


3 


1 


TNSTAT 


SEE SAME PARAMETER UNDER 2436 3 
MOVE FOR VALUES 243fi 


4.5 * ASSIGN 


6 FILE NAME 


244 5 

i 


LOGICAL TAPE NUMBER 245 3 

IF VALUE TYPE EQ 4 DISPATCH-2452 1 
ER ASSIGNS TAPE AND LEAVES 2454 
LOGICAL TAPE NUM IN VALUE 2456 


PNAME 


6 ' 6 


PROGRAM NAME OF PROG. USING 
FILE IF NOT SAME AS CALLING 
PROGRAM 


2458 3 

24585 

24586 


TTYCHN 


0 


TELETYPE NUM FIRST-0 


246 3 


4.6 * MOVE 


6 6 
0 


FILE NAME 241 
RELATIVE LOCATION IN SYSTEM246 
lABLES OF ENTITY TO BE 24 c 
MOVED 2 5 C 
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237 3 

238 

239 

240 

241 

242 

243 

-f 2432 1 
•N 2434 


IDENT CHARACTERS FOR TAPE 
TRANSFERS - CAUSES THIS 
READ OR WRITE TO BE IN 
IDENT MODE 


NUMWDS (3) 


NUMBER OF WORDS TO BE MOVE 


2436 3 
2438 


INPUT ( 2 ) 


OUTPUT ( 2 ) 


CAUSES TRANSFER TO CORE 

CAUSES TRANSFER FROM CORE 


244 5 


I 


COREIX (1) 


NUMBER TO BE ADDED TO INL 
OF FILE DECLARATION TO 
ESTABLISH MODIFED INLOC F 
THIS TRANSFER ONLY 


245 3 

H-2452 1 
2454 
2456 


DRUMIX (1) 


NUMBER TO BE ADDED TO DRUl 
REGISTER AS DEFINED OR 
REQUESTED IN DRMLOC OF FI 
DECLARATION 


2458 3 

24585 

24586 


TTYCHN (4) 


TELETYPE NUM FIRST =0 



THIS ITEM SET BY DISPATCHEf 
AT COMPLETION OF MOVE IF 
PROVIDED BY CALLING PROGRA! 
0 = INITIAL DISP SETTING 
1 ^REQUEST IN STACK 
2 =REQUEST IN OPERATION 
3 =REQUEST COMPLETE 
4 =READ REQUEST FOUND EOF, 
OPERATION COMPLETE 
5 =READ REQUEST FOUND EOT, 
OPERATION COMPLETE 
6=IF TAPE WRITE 

WROTE OVER TAPE END 
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IF DRUM READ OR WRITE 26444 
STEPPED TO ILLEGAL FIELD26446 
7=REQUEST RESULTED IN 26450 

ILLEGAL TAPE MOTION 26452 

8= AN UNFIXABLE PARITY 26454 

OCURRED 26456 

9 REQUEST REJECTED-ILLEGAL 26455 
(THESE VALUES NOT SET ) 26458 

(ON TELETYPE MOVES ) 26460 


WDSIN 


DISPATCHER INSERTS NUMBER 2647 3 
WORDS READ FROM TAPE IF 2648 
PROVIDED 2649 


I 


COMMENTS 


265 3 


(1) OPTIONAL 

(2) EITHER INPUT OR OUTPUT -BUT NOT BOTH- ARE USED 

IF USED OVERRIDES FILE 

(3) NOT NEEDED IF GIVEN IN FILE DECLARATION* 

(4) OPTIONAL - IF USED WITH FILE DECLARED AS TTY IT WILL 
BY TTY CHANNEL USED (THIS MOVE ONLY ) 


266 

267 

26701 

26705 

26707 

26709 



1 

! 


4.7 * SCROLL 

,1 


6 FILE NAME IDENTIFIS AREA 2671 5 

NOW ON DRUMS TO BE GIVEN 2673 
INDEPENDENT IDENTITY 2675 


NAME 


6 '6 NEW NAME OF ENTITY 2677 


4.8 * TOCORE 


PQU CHANNEL OF PROGRAM 269 5 


4.9 * TODRUM 


PQU CHANNEL OF PROGRAM 270 5 


§ 
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26444 
. 1^26446 
26450 
26452 
26454 
26456 
- 26455 
26458 
26460 


# ?) 

5.0 * DELETE 


5.1 * LOAD 


6 NAME IN INVENTORY 


CHANNEL IN PQU OF PROGRAM 
TO BE LOADED 


2647 3 

2648 

2649 5.2 * DIRECT 


265 3 


266 

267 

26701 

26705 

26707 

26709 



5.3 * CON 


2671 5 

2673 

1675 


!677 


NEXT THREE WORDS CONTAIN 
I/O CALL IN FORMAT OF I/O 
PACKAGE. THERE WILL BE 
LEGALITY CHECKS ON THIS 
REQUEST. USE ONLY AFTER 
CHECKING WITH SYSTEM 
DESIGNERS. 


INTEGER IS CHANNEL NUMBER 
IN QUEUE OF PROGRAM TO BE 
CHECKED FOR CONFLICTS. 
DISPATCHER INSERTS IN BYTE 
OF WORD CONTAINING CON 
0=NO CONFLICT 
1=PGM ( S ) IN CONFLICT 
BUT CAN NOW BE MOVED 
2=CONFL I CT PROGRAM ( S ) 
NOW DOING I/O 
3=CONFL I CT WITH PROGRAM 
IN PCUR 


269 5 


5.4 * IOCINT 


THIS INDICATES AN 10 
COMPLETE INTERRUPT - USED 
ONLY BY SYSTEM 



( 1 ) 


5.5 * JOIN 


0 


TELETYPE NUM, FIRST=0 


9 
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COMMENTS 


9 

295 


(1) TELETYPE STATION (CHANNEL) NO. IS ONE HIGHER THAN 
TELETYPE ''UMBER REFERENCES IN DISPATCHER CALLS 
E.G. * STATION 1=0. 

JOIN CALL MUST BE GIVEN SEPARATELY FOR EACH ADDED 
STATION, INCLUDING ORIGINAL STATION . 


297 

298 

299 

300 

301 


5.6 * RESCUE (1) 


ERROR RECOVERY ADDRESS l'N 302 
OBJECT PROGRAM LOCATION. 303 


COMMENTS 


304 


(1) SYSTEM WILL BRANCH TO SPECIFIED RECOVERY ADDRESS 
AFTER ERROR INTERRUPT AND DEPOSIT ERROR INDICATOR 
IN BYTE 7 OF NEXT REGISTER . 

VALUE OF BYTE 7 = ERROR CONDITION- 


1 = ILLEGAL BRANCH TO FIX 

2 = ILLEGAL INSTRUCTION 

3 = ILLEGAL ADDRESS REFRNCE 

4 = ILLEGAL DIVISION 

5 = PROGRAM HALT 


305 

306 

307 

308 

309 

310 

311 

312 

313 



fin 




6/poi/oi 


295 

297 

298 

299 

300 

301 


302 

303 


304 

305 

306 

307 

308 

309 

310 

311 

312 

313 


*f) 1 
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TELETYPE (MODEL 28) AND HOLLERITH CHARACTER SETS 
FOR TSS-1 


28 

TTY 

CHARACTER 

HOLLERITH 

CHARACTER 


SORTABLE 
(IN STORAGE) 


NON- 

SORTABLE 
(6 n TAPE) 

Space 1 

Blank 

60 

110 000 

20 

010 000 


0 

00 

000 000 

12 

001 010 

1 

1 

01 

000 001 

01 

000 001 

2 

2 

, 02 

000 010 

02 

000 010 

3 

3 

03 

000 011 

03 

000 011 

b 

b 

(* 

000 100 

03 

000 100 

5 

5 

05 

000 101 

05 

000 101 

6 

6 

06 

000 110 

06 

000 110 

7 

7 

07 

000’ 111 

07 

poo 111 

8 

8 

10 

001. 000 

10 

001 000 

9 

1 

9 

11 

001 Q01 

11 ' 

001, 001 

1: 

“ 

13 

001 Oil' 

13 

001 011 

f 

.1 

1 

14 

001 100 

lb 

001 100 

& 

- + 

20 

010 000 

60 

110 000 

• 

• 

33 

Oil Oil 

73 

111011 

) 

) 

3^ 

011 100 

7^ 

111 100 

— . 

— 

■bo 

• 

100 000 

4 o 

100 000 

$ 

$ 

53 

101 011 

53 

101 011 

# 

* 

5 b 

161 100 

5 b 

101 100 


' L T hese teletype characters will be replaced by the Hollerith equivalents „ 



19 July 1963 


TM-1126/ 001/ 01 



28 

TTY 

CHARACTER 

HOLLERITH 

CHARACTER 


SORTABLE 
(IN STORAGE) 


NON- 
SORTABLE 
(ON TAPE) 

/ 

/ 

61 

110 001 

21 

010 001 

) 


73 

111 Oil 

33 

Oil Oil 

( 

( 

74 

111 100 

34 

011 100 

A 

A 

21 

010 001 

61 

no 001 

B 

B 

22 

010 010 

62 

no 010 

C 

C 

23 

010 011 

63 

no 011 

D 

D 

24 

010 100 

64 

110-100 

E 

E 

25 

010 101 

65 

no 101 

F 

F 

26 

010 no 

66 

110 110 

G 

G 

27 

010 111 

67 

110 111 

H 

H 

30 

011 000 

70 

111 000 

I 

I 

31 

011 001 

71 

111 001 

J 

J 

4 l 

100 001 

4 l 

100 001 

K 

K 

42 

100 010 

42 

100 011 

L 

L 

43 

100 011 

43 

100 100 

M 

M 

44 

100 100 

44 

100 101 

N 

N 

45 

100 101 

45 

100 110 

0 

0 

46 

100 no 

46 

100 m 

P 

P 

47 

100 111 

47 

101 000 

Q 

Q 

50 

101 000 

50 

101 001 

R 

R 

51 

101 001 

51 ' 

101 010 

S 

S 

62 

no 010 

22 

010 011 

T 

T 

63 

110 011 

23 

010 011 

U 

U 

64 

110 100 

24 

010 100 

V 

V 

65 

no 101 

25 

010 101 

W 

w 

66 

110 110 

26 

010 110 

X 

X 

67 

no 111 

27 

010 m 

Y 

Y 

70 

111 000 

30 

011 000 

Z 

z 

71 

111 001 

31 

011 001 


l 

I 

I 
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1 'll 

0 ) 1 



28 

TTY 

CHARACTER 


SORTABLE 
(IN STORAGE) 


NON- 

SORTABLE 
(ON TAPE) 

» 

55 

101 101 

55 

101 101 

• 

36 

Oil no 

36 

on 110 

BELL 

77 

m m 

77 

111 111 

lf/cr 

32 

011 010 

32 

011 010 


76 

111 110 

76 

111 110 

»i 

56 

101 110 

56 

101 110 


Model 28 Teletype 
characters only. 





2 


End-of-message 



! 

: 


[ 
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APPENDIX C 

TIME-SHARING SYSTEM OUTPUT MESSAGE LIST 


The following list describes the current output messages that the Time- 
sharing System (TSS-l) will produce on the user’s teletype under various 
conditions. In some cases, the exact wording of a message may he changed 
from the form shown below, but the content will remain essentially the same. 


A. Executive Program Source - Teletype 

1. TIME SHARING SYSTEM ON THE AIR 

2. $TRNSMSN ERR, REPEAT 

3. $MSG IN 

k. $WAIT 

5. $CANCLD 

6. $COMND ILLEGAL FOR PCM STATUS 

7. $BLK FULL, PROC AS EOM 


Input Interpreter 

- Printed out on all teletypes when 
the system starts operating. 

- Teletype input message transmission 
incorrect; repeat input. 

- Any Executive command which has 
been received and processed will 
produce this acknowledgement. 

- When a delay is anticipated in 
processing a user's request 
(Executive command), due to 
operator activity, the system 
will notify the user to "WAIT." 

This will primarily occur during 
tape mounting actions. 

- In response to CANCEL command (3 
line feeds), current input message 
has been discarded. 

- The Executive command received is 
not legal for the current status 
of the user's program, e.g., a 
program STOP cannot be given if 
the program has not been given a 
GO after loading. 

- If a long input message fills the 
input buffer's capacity, the system 
will process the input characters 
received up to that point without 
the need for an EOM (BELL), (if 

a long input is desired, enter the 
later characters slowly, so that 
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same. 

when 

mission 

3 

rfill 


0 

l." 

ring 

1 (3 
essage 

ed is 
c^us 

-f 
en a 


s the 
system 


the system can process the first 
buffer-full portion before suc- 
ceeding characters clobber prior 
input . ) 

8 . ^ILLEGALITY IN PARAMETER N R , - The value of an Executive comman 

parameter is illegal. The comma 
must be repeated with legal, 
parameter values. 

- The Executive command received 
does not contain the proper numb 
of parameters required. 

- The input parameter for the DIAL 
command does not specify a legal 
channel number address, e.g., if 
the sender’s channel number is 
given as the address. 

- This is the header which precede 
a DIAL message output to a recei 
The header indicates both the 
sender’s channel number and the 
addressees channel number. 

- If user asks for DBUG function 
before his object program is 
available (i.e., loaded) repeat 
request after $LOAD OK is recei-\ 

NOTE: The system will refer all Executive mode inputs which it does not 
understand to the Debugging program. If DBUG cannot accept the input, 
it will print out an error* message (e.g., ERR1, ERR 7, etc.). See 
TM- H26 /oo 4/00, page 13 , for DBUG error messages. 

B. Executive Program Source - FIX Interface 

All object programs which are trapped through the FIX interface because 
of an illegality will be set to a status of "logical conclusion, " with 
one of the error printouts listed below. At this point,- the program 
may be restarted by setting the Live Register (via DBUG) to an appro- 
priate location in the object program, and giving the GO command. 


SENT AS 


9. $INSFCNT NR FRMETERS 


10. $N0 RECVR FOR DIAL 


(jj)j Q 11. XX TO XX (MESSAGE) 


12. $TRY AGAIN 
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1. PCM TERMINATED ON ILLEGAL 
ADDRESS REFERENCE AT XXXXXX 


2. PCM HUNG ON AN ILLEGAL 
DIVISION AT XXXXXX 


3" PCM HALTED AT XXXXXX 


h . PCM TERMINATED ON AN INDETER- 
MINATE ERROR 


5- PCM WAS TRAPPED ON ILLEGAL 
REENTRY LOCATION AT XXXXXX 


60 PCM WAS TRAPPED ON ILLEGAL 
INPUT DATA LOCATION 


7. PCM WAS TRAPPED ON ILLEGAL 
DOUBLE INDEX 


- System has trapped an object program 
which exceeds the upper or lower 
limits of the computer (30 > x > 65 k). 
The printout gives the Program 
Counter (address) at time of inter- 
rupt, which may he off by one 
register. 

- The object program has been inter- 
rupted when trying to perform an 
illegal division. Address indi- 
cates location of division 
instruction. 

- An object program which executes 

a halt (any register with a ll zeros) ' 
will be trapped by the system. 

Object programs, when logically 
concluded, should branch to the 
system (BUG 303’)“ 

- If an unaccountable error has 
caused FIX to interrupt the system, 
the currently operating object 
program user will be notified of 
the situation with this printout. 

- If the branch address in the Live 
Register for an object program ex- 
ceeds the upper or lower system 
limits (l 6 k > x > 64k), the program 
will be trapped. The address in 
the Live Reg will be indicated in 
the printout. 

- This condition is similar to 5, 
above, except that it applies to 
illegal locations specified for 
input data transfers (via i/o 
calls) . 

- If double index has an illegal 
number of bits for its assigned 
value, program will be trapped. 
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- Any bad instruction caused by objec 
program error or any other reason 
will result in this trap and print- 
out. 

- If FIX determines that it has been 
entered illegally, the system will 
terminate the currently operating 
object program. 

* 

- This is not an error printout, but 
merely notice that the object progr 
has completed its run and returned 
control to the system. It may be 
operated again by setting the Live 
Reg to the starting address, and 
giving the GO command. 

C. Executive Program Source - Dispatcher 

|)| ) The Dispatcher is responsible for all i/o transfers and will generate 

appropriate error messages if any i/o call is in error. In addition, 
the Dispatcher will communicate information concerning tape handling 
operations . 

1. $LOAD OK 


2. $N0 LOAD 

9 

3. $xx TAPES AVBL 

I 

4. $FILE XXXX DRIVE XX REEL 

I 


In certain cases of program or machine error, where the system may stop 
operating, the operator may enter the "logical conclusion" address to 
continue the system. This would cause a PROGRAM CONCLUDED message to appear 
on the user's teletype, and would indicate that a manual termination (due to 
some error) was implemented. As the system evolves, this problem will be 
treated in a better manner. 


•J, D 


- Binary object program has been 
loaded from tape to drums in 
response to the LOAD command. 

- Binary object program could not be 
loaded from tape to drum for some 
reason. 

- In response to user's input request 
for number of tape drives available 
(Current maximum is five for object 
programs . ) 

XXXX - Indicates to user reel number of a 
"mount" tape requested by object 
program during 'its operation. This 
reel number should be referenced 
for later use of tape, if necessary 


5k)< 


8. PGM HUNG ON AN ILLEGAL INSTRUC- 
TION AT XXXXXX 


9. PGM TERMINATED ON ILLEGAL 
BRANCH INTO FIX 


10. PROGRAM CONCLUDED 
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5" BAD LOCN 


The succeeding Dispatcher 
as follows: 


- Object program indicates a location 
(in Accumulator) for i/o call table 
which exceeds upper or lower system 
address limits (24 > x > 65k) . Pro- 
gram will be put into STOP status,, 

error messages will appear in a general format 


aaaaaaaaaa aaaa 

Error Type Program Ident 


AAAAAAAA 

Location 

I/O Call in Error 


maPATCHER CALL ERROR 


The object program will be placed ir 
occur. The user may be able to take 
the RESUME commando 


a STOP status if the errors below 
corrective action (using DBUG) and 


6. 

NO FILE 

" X I 11 * n ,TL fOUnd t0 flle reference in call 

l e °’ a MOVE call must have a FILE declared previously) 
May appear as EMOVEA. currestlv. P viousiy; 

7- 

NO NUMWD 

- The NUMWDS parameter is missing from both the FILE and 
subsequent MOVE calls. It must be in at least oS S 

8. 

. CORE ADD 

" Specified ^ object program for an i/o transfer 

exceeds^upper and^lower address limits of system • 

9- 

ILL ID R 

- Illegal ID read for tape (i.e., ID given in binary). 

10. 

NO OPTN 

No OPTION parameter specified for TAPMUV call. 

11. 

BAD OPTN 

Illegal parameter value specified for OPTION. 

12. 

EL TAPE 

- Object program has specified a logical tape drive for 
tape usage. This is legal only for system programs. 

13. 

NO TAPES 

" available? 31 ” 8111 &Sked f ° r a tape drive none are 

l4„ 

ILL CHAN 

- Non-existent i/o channel specified for joining several 
user channels to one program. 



L 
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ie 

an 

15. 

BAD CHAU 

- Specified channel not in proper status to be joined 
to originator's program. 


16. 

NO CALL 

- Object program has not specified location of recognizabl 
i/o call table in Accumulator at time of branch to 
Dispatcher. 


17. 

VAL TYPE 

- Illegal Value Type specified in call. 


18. 

DREQ OVR 

- Dispatcher overloaded with i/o requests and cannot 
accept any more for stacking. (This situation 
although possible, should hopefully never occur. ) 


19. 

ILL READ 

- Object program has asked for an i/o read which will 
exceed the address limits of the object programs core 
space allocation. 

1. 

20. 

MOVER 

- The INPUT or OUTPUT parameter is missing from a MOVE 
call . 
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